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SUMMARY 


The  Air  Force  Human  Resources  Laboratory  is  developing  a  demonstration 
prototype  Integrated  Maintenance  Information  System  (IMIS).  The  IMIS  will  be  an 
automated  system  designed  to  provide  the  maintenance  technician  with  a  single  source  for  all 
information  necessary  to  do  his  or  her  job.  It  will  include  technical  order  information, 
diagnostics  information,  maintenance  records,  supply  information,  management 
information,  and  training  materials.  The  Laboratory  is  conducting  a  systematic  program  to 
develop  the  technologies  required  for  the  IMIS.  Diagnostics  aiding  techniques  have  been 
developed  as  part  of  this  program.  These  techniques  are  incorporated  in  the  IMIS 
Diagnostic  Module  (IMIS-DM).  The  IMIS-DM  is  now  ready  for  testing.  This  report 
describes  the  first  of  two  efforts  designed  to  demonstrate  and  test  the  IMIS-DM. 

The  IMIS  Diagnostics  Demonstration  was  conducted  at  Homestead  AFB,  Florida,  in 
May  1989.  The  F-16  Fire  Control  Radar  was  used  as  the  testbed  for  the  demonstration. 

The  project  demonstrated  that  a  small,  portable  computer  can  interface  direcdy  with  the 
MIL-STD-1553  multiplex  control  bus  of  the  F-16,  act  as  bus  controller,  initiate  built-in 
tests,  read  and  analyze  the  resulting  fault  data,  provide  diagnostic  advice  to  maintenance 
technicians,  and  present  automated  technical  procedures  to  guide  the  technician  in 
performing  tests  and  corrective  maintenance.  The  IMIS-DM  was  tested  by  having 
technicians  use  the  system  to  perform  troubleshooting  tasks  on  the  radar  system.  The 
technicians  were  able  to  successfully  solve  all  troubleshooting  problems  used  in  the 
demonstration.  The  demonstration  results  indicate  that  the  IMIS-DM  will  provide  an 
effective  diagnostic  capability  for  the  IMIS  and  will  provide  the  basis  for  significant 
improvements  in  the  ability  of  Air  Force  maintenance  personnel  to  perform  diagnostic  tasks. 
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PREFACE 


This  report  summarizes  research  and  development  (R&D)  accomplished  under 
Project  2950,  Integrated  Maintenance  Information  System  (IMIS),  Work  Unit  2950-00-06, 
F- 16  Diagnostics  Demonstration.  The  purpose  of  the  study  was  to  demonstrate  the 
diagnostic  technology  developed  for  the  Integrated  Maintenance  Information  System 
(IMIS). 

The  IMIS  Diagnostic  Demonstration  (IMIS-DD)  provided  the  first  test  of  the  IMIS 
diagnostic  capability  in  an  operational  environment.  General  Dynamics  Electronics  (GDE) 
Division  was  the  prime  contractor  for  the  effort.  However,  accomplishment  of  the  effort 
required  the  coordinated  support  of  several  other  organizations.  The  major  portion  of  the 
technical  data  development  was  accomplished  in-house  by  AFHRL  staff  scientists.  The 
software  for  the  diagnostics  module  was  developed  by  Systems  Exploranon,  Inc.  (SEI). 

The  portable  maintenance  aid  (PMA)  and  Authoring  and  Presentation  System  software  used 
for  the  study  were  developed  by  AITIRL  in-house,  with  extensive  support  from  Systems 
Research  Laboratories  (SRL).  Support  for  the  field  test  portion  of  the  study  v,as  provided 
by  SEI  and  Applied  Science  Associates  (under  contract  with  GDE). 

Many  Government  and  contractor  personnel  played  significant  roles  in  the  effort. 
Key  personnel  are  identified  below. 

Air  Force  Human  Resources  Laboratory 

Terry  Miller.  Originated  the  diagnostic  techniques  which  provide  the  basis  for  the 
IMIS  diagnostic  module. 

Captain  Randy  Link.  Served  as  Program  Manager  for  most  of  the  effort,  and 
director  of  many  of  the  modifications  to  the  data  base  authoring  system. 

Lieutenant  Janet  Murphy.  Served  as  Program  Manager  for  the  last  part  of  the 
project  and  responsible  for  data  development,  validation,  and  evaluation  of  the  final 
product. 

Captain  Dwayne  Mason.  Developed  and  improved  the  diagnostic  module  and 
provided  general  support  throughout  the  effort. 

Captain  Mark  Earl.  Designed  and  developed  the  authoring  software. 

Gail  Hudson.  Directed  the  development  of  the  portable  maintenance  aid  used  in  the 

study. 


Captain  Gail  McCarty.  Developed  the  maintenance  data  base. 

Dr.  Donald  Thomas.  Provided  technical  support  throughout  the  project. 

31  Tactical  Fighter  Wing.  Homestead  AFB,  FL 

Colonel  James  Cushman,  Deputy  Commander  for  Maintenance.  Provided  the 
facilities  and  personnel  required  for  the  field  demonstration. 

SMSgt  Prince,  SMSgt  Bolton,  and  TSgt  Manka.  Coordinated  Wing  support  for  the 
demonstration  and  provided  technical  guidance. 
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General  Dynamics  Electronics 


James  Brown.  Served  as  Project  Manager  for  development  of  the  aircraft  interface 
software,  portions  of  the  data  base,  and  testing  of  the  final  product. 

Neal  Ostrem.  Developed  the  1553  bus  software  that  interfaces  with  the  F-16 

aircraft. 


Mike  McKnemey.  Developed  modifications  to  the  presentation  software  to 
accommodate  access  to  the  aircraft. 

General  Dynamics  Ft.  Worth  fHill  AFB  office) 

Lloyd  Huff,  Phil  Ralphs,  and  Curtis  Ockerman.  Assisted  with  development  of  the 
diagnostics  data  base  and  testing  of  PMA/F- 16  data  bus  interface. 

Applied  Scigace_A  ssocia  tes  Jn  c. 

Reid  Joyce.  Provided  guidance  to  GDE  in  the  area  of  Human  Factors  and  served  as 
data  collector  for  the  field  demonstration. 

Systems  Exploration.  Inc. 

Garth  Cooke.  Managed  the  effort  to  develop  the  IMIS  Diagnostic  Module 
algorithms  and  software. 

Johnnie  Jemigan.  Assisted  in  the  development  of  the  diagnostic  module 
algorithms,  selected  the  problem  set  used  in  the  demonstration,  and  provided  technical 
assistance  for  the  field  demonstration. 

Systems  Research  Laboratories  (SRL) 

Jerry  Brainard.  Managed  SRL  activities  in  support  of  the  development  of  the  PMA 
and  APS  software,  and  provided  technical  assistance  during  the  field  demonstration. 

Jane  Slayback.  Led  the  team  of  programmers  that  developed  the  APS  and  PMA 
software. 

Rick  Chaney,  John  Miles,  and  Chris  Broadbent.  Provided  technical  assistance  for 
the  demonstration. 

Dave  Groomes.  Developed  the  graphics  for  the  data  base  used  for  the 
demonstration. 
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I.  INTRODUCTION 


Recent  developments  in  information  processing  technology  and  computer  design  have 
made  possible  the  automation  of  many  maintenance  information  processes  that  were  traditionally 
manual  operations.  These  processes  include  interacting  with  maintenance  data  bases,  obtaining 
and  using  technical  orders  and  instructions,  downloading  and  evaluating  aircraft  built-in-test  (.BIT,) 
results,  and  using  historical  data  to  diagnose  aircraft  malfunctions. 

A  number  of  automated  information  systems  have  been  developed,  or  are  under 
development,  to  automate  these  processes  for  use  by  Air  Force  maintenance  technicians. 

However,  these  systems  are  being  developed  independently,  and  as  a  result,  use  different 
computer  hardware  and  human/computer  interaction  techniques.  This  requires  the  technician  to 
learn  to  use  several  complex  systems,  making  his/her  already  difficult  job  more  difficult.  A  single 
system  is  needed  which  integrates  all  of  the  information  systems  so  that  they  may  be  accessed 
using  common  hardware  and  human/computer  interaction  protocols.  With  such  a  system,  the 
technician  would  be  required  to  learn  only  one  set  of  protocols  to  use  the  system  to  obtain  the 
information  necessary  to  do  the  job. 

The  Air  Force  Human  Resources  Laboratory  (AFHRL)  has  established  the  Integrated 
Maintenance  Information  System  (IMIS)  program  to  meet  this  need.  The  Laboratory  is 
systematically  developing  and  evaluating  the  capabilities  required  for  the  IMIS.  The  present  report 
describes  the  work  performed  in  a  recently  completed  effort  to  develop  and  evaluate  key 
capabilities,  the  IMIS  Diagnostics  Demonstration  (IMIS-DD). 


Definition  of  the  IMIS  Program 

IMIS  is  a  demonstration  prototype  maintenance-aiding  system  that  will  communicate  with 
other  m'mtenance  computer  systems,  both  on-aircraft  and  ground-based,  to  provide  a  single 
source  of  information  to  meet  the  information  requirements  of  maintenance  personnel.  IMIS  will 
access,  integrate,  and  display  maintenance  information  for  base-level  aircraft  maintenance 
technicians.  The  IMIS  will  include  interactive  interfaces  with  the  computer  systems  on  the  aircraft 
and  with  maintei..,i.ce  and  management  ground-based  computer  systems.  In  addition,  it  will 
operate  independently  for  stand-alone  troubleshooting  and  corrective  maintenance  tasks. 

Technicians  will  -ise  a  portable,  ruggedized  computer  as  the  single  information  access  unit 
for  all  the  data  needed  to  accomplish  maintenance  tasks.  The  system  will  display  graphic  and 
procedural  technical  instructions,  provide  intelligent  diagnostic  advice,  provide  aircraft  battle 
damage  assessment  and  repair  aids,  interrogate  aircraft  BIT  systems,  and  analyze  in-flight 
parameter  data  and  aircraft  historical  data.  It  will  also  provide  easy,  efficient  methods  for  the 
technician  to  receive  work  orders,  report  maintenance  actions,  order  parts,  complete  computer- 
aided  training  lessons,  and  transmit  messages  throughout  the  maintenance  complex.  As  originally 
envisioned  by  AFHRL  scientists,  the  IMIS  system  will  consist  of  five  major  elements: 

1.  The  technician's  nortahle  m;iintf>nnnrr>  .tiH  1PM4) 

2.  Maintenance  information  workstation  (MIW)  in  the  maintenance  complex  connected  to 
the  ground-based  computer  systems  and  networks. 

3.  Aircraft  interface  panel  (AIP)  for  interfacing  with  aircraft  computers  and  sensors. 
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4.  Integration  software  that  combines  the  information  from  multiple  sources  and  presents 
the  data  in  a  consistent  way  to  the  technician. 

5.  Applications  software  that  uses  information  from  various  sources  to  assist  in 
troubleshooting  and  identifying  the  causes  of  malfunctions  and  performing  maintenance. 


IMIS  Diagnostics  Demonstration 

The  IMIS-DD  project  was  a  proof-of-concept  demonstration  of  several  key  aspects  of  the 
IMIS  program.  These  concepts  included  the  use  of  a  computer-based  PMA  to  provide  intelligent 
diagnostic  advice  for  the  technician,  interfacing  the  PMA  with  the  aircraft  data  bus,  and  integrating 
maintenance  technical  data  with  the  diagnostic  advice.  The  primary  objective  of  the  effort  was  to 
test  and  demonstrate  the  diagnostic  capability  provided  by  the  IMIS  Diagnostic  Module  (IMIS-DM) 
and  not  to  test  a  fully  capable  IMIS  system.  All  areas  of  the  IMIS  ,  including  those  tested  in  the 
IMIS-DD,  continue  to  be  researched,  evaluated,  and  enhanced.  The  diagnostic  capabilities 
demonstrated  for  the  IMIS-DD  include: 

1 .  automated  generation  of  diagnostic  advice. 

2.  concepts  for  presenting  diagnostic  guidance  such  as  giving  the  technician  the  choice  of 
whether  or  not  to  follow  recommendations,  and  providing  decision  support  information  (e.g., 
component  probability  of  failure  data). 

3.  integrating  diagnostic  instructions  with  maintenance  instructions. 

4.  interfacing  the  PMA  with  the  aircraft  MIL-STD-1553  (1978)  data  bus  to  initiate  the  BIT 
and  obtain  aircraft  systems  status  information. 

In  addition,  the  effort  addressed  several  secondary  objectives,  including: 

1 .  testing  techniques  for  presenting  technical  data  on  a  PMA. 

2.  testing  human  computer  interface  techniques  for  presenting  diagnostic  and  technical 

data. 

3.  demonstrating  the  use  of  a  "neutral,''  format-free  data  base  for  maintaining  maintenance 
technical  data.  * 

4.  testing  the  capability  of  the  AFHRL  Authoring  and  Presentation  System  (APS)  to  create 
data  in  a  neutral  format,  and  presenting  the  data  on  a  PMA. 

5.  testing  the  capability  of  the  APS  to  handle  technical  data  for  several  aircraft 
configurations,  and  automatically  presenting  the  proper  data  for  a  specific  aircraft. 


1 A  neutral  data  base  contains  no  format  information  to  control  the  presentation  of  the  data. 
Tne  data  include  the  data  elements  (information  to  be  presented)  plus  codes  which  identify  the  type 
of  information  (e.g.,  header,  graphic  or  procedural  step).  Rules  for  formatting  the  data  are 
incorporated  in  the  software  used  to  present  or  print  the  data. 


2 


Background 


For  several  years  AFHRL  has  conducted  a  systematic  research  and  development  (R&D) 
program  to  develop  the  technologies  required  for  the  IMIS.  To  date,  these  efforts  have 
concentrated  on  the  development  of  techniques  to  (a)  use  computers  to  present  maintenance 
technica1  -*ata,  (b)  provide  economical  techniques  for  creating  and  storing  technical  data  on 
computet  ystems,  (c)  use  computers  to  create  and  present  automated  diagnostic  advice  for 
technicians,  and  (d)  provide  effective  techniques  for  humans  to  interact  with  the  computer  to  obtain 
the  information  that  they  need.  This  research  has  resulted  in  the  development  of  prototype 
computer-based  technical  data  systems  for  intermediate-level  and  on-equipment  maintenance;  the 
IMIS-DM;  an  authoring  system  for  creating  technical  data  in  a  neutral  format;  a  presentation  system 
for  displaying  the  data  on  a  variety  of  computers;  and  specifications  for  use  in  procuring  technical 
data  in  a  neutral  format.  In  addition,  work  is  presently  in  progress  to  conduct  a  more 
comprehensive  test  of  the  IMIS-DM  and  to  develop  a  full-scale  prototype  IMIS  to  fully  test  the 
IMIS  concept.  Earlier  efforts  which  have  had  a  major  influence  on  the  IMIS-DD  effort  are  briefly 
described  below.  Efforts  which  played  a  major  role  in  the  IMIS-DD  are  described  in  detail  in 
Section  II. 


Computer-Based  Maintenance  Aids  (CMAS) 

Since  1976,  AFHRL  has  conducted  R&D  to  develop  the  technology  for  the  presentation  of 
technical  data  on  an  automated  system  (Thomas  and  Clay,  1988).  This  research  recognized  the 
potential  of  an  automated  technical  data  system  to  improve  performance  of  maintenance  personnel 
and  reduce  the  cost  of  maintaining  the  Air  Force  technical  data  system.  Emphasis  was  placed  upon 
the  design  of  technical  data  presentation  techniques  and  procedures  tailored  to  meet  technicians’ 
needs.  Emphasis  was  also  placed  upon  developing  data  access  techniques  to  make  it  easy  for 
technicians  to  locate  needed  information  and  developing  effective  formats  for  presenting  that 
information.  Experienced  maintenance  personnel  from  operational  units  were  involved  in  all 
phases  of  the  program  (as  consultants  and  test  subjects)  to  ensure  that  the  needs  of  the  maintenance 
technician  were  met  and  the  techniques  developed  were  suitable  for  use  in  actual  maintenance 
operations. 

A  laboratory  demonstration,  two  prototype  systems  for  off-equipment  maintenance,  and 
two  prototype  systems  for  on-equipment  maintenance  were  developed  in  the  CMAS  project. 
Although  the  prototype  systems  were  not  intended  for  actual  operational  implementation,  they  were 
designed  to  fully  test  all  required  functions  and  to  accurately  simulate  an  operational  system.  The 
prototypes  were  tested  in  maintenance  shops  of  operational  units  to  provide  realistic  evaluations  of 
the  systems  under  operational  conditions.  Specifications  for  both  (a)  technical  data  content  and  (b) 
system  hardware  and  software  were  developed  based  upon  the  knowledge  gained  from 
development  of  the  prototypes  and  from  experience  gained  in  the  field  tests. 

The  basic  approach  taken  to  achieve  the  project  objective  was  to  first  conduct  feasibility 
studies  of  a  CMAS,  identify  the  basic  features  that  should  be  provided  by  such  a  system,  develop 
and  evaluate  prototype  systems,  and  develop  draft  specifications  for  use  in  developing  and 
procuring  systems  for  operational  use.  The  feasibility  studies  were  accomplished  and  four 
prototype  systems  were  developed.  Evaluations  of  three  prototypes  were  performed;  the  fourth 
prototype  was  evaluated  in  die  IMIS-DD  project. 

The  feasibility  studies  and  prototype  evaluations  achieved  the  following  results: 

1.  established  the  feasibility  of  automated  technical  data  presentation  systems, 

2.  demonstrated  they  can  effectively  present  technical  data  for  use  by  technicians. 
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3.  demonstrated  technicians  will  readily  accept  and  use  automated  technical  data 
presentation  systems, 

4.  demonstrated  that  diagnostic  procedures  can  be  effectively  presented  on  a  CMAS,  and 

5.  provided  the  basic  human  factors  requirements  for  a  CMAS. 

The  information  gained  from  the  feasibility  studies  and  evaluations  of  the  first  three  prototypes 
provided  the  basis  for  the  development  of  the  fourth  prototype,  the  Portable  Computer-Based 
Maintenance  Aids  System  II  (PCMAS  II).  The  PC MAS  II  computer  was  used  as  the  PMA  for  the 
IMIS-DD  effort. 

The  PCMAS  II  computer  was  developed  to  provide  a  small,  rugged,  lightweight  computer 
system  for  use  in  evaluating  techniques  for  presenting  technical  data  and  diagnostic  advice  for  on- 
equipment  maintenance.  It  was  based  upon  an  earlier  prototype  (PCMAS  I)  which  was  found  to 
be  too  slow  to  generate  the  graphics  required  for  presentation  of  technical  data.  The  PCMAS  II 
computer  weighs  15  pounds  and  its  dimensions  are  15  x  12  x  3  inches.  Technical  data  for 
presentation  on  the  system  are  maintained  in  removable,  3-megabyte  memory  cartridges.  The 
PCMAS  II  is  operable  from  a  battery  pack  (6-  to  8-hour  capacity),  aircraft  system  power,  an 
auxiliary  power  unit,  or  standard  commercial  power  (1 10V  AC).  The  keypad  consists  of  eight 
programmable  function  keys,  a  numeric  keypad,  and  cursor  control  keys.  A  built-in  1553  data  bus 
board  provides  the  capability  to  communicate  directly  with  aircraft  systems  served  by  the  aircraft’s 
MIL-STD-1553  data  bus.  The  PCMAS  II  may  be  operated  in  a  stand-alone  mode  or  in  conjunction 
with  a  workstation  that  orovides  a  full  keyboard,  hard  disk  drive,  printer,  and  additional 
communication  capabilu.es.  Software  developed  for  the  system  includes  a  UNIX-based  operating 
system  and  applications  software  for  diagnostic  aiding  and" presentation  of  technical  data. 

The  PCMAS  project  is  described  further  in  Section  II. 


APS  Project 

In  conducting  the  CMAS  program,  it  was  recognized  that  the  manner  in  which  the  data  base 
is  created  and  maintained  will  have  a  significant  influence  on  the  success  of  an  automated  technical 
data  system.  Efficient  techniques  must  be  available  to  create  the  data  and  incorporate  the  complex 
coding  required  for  the  display  of  technical  data  on  a  screen.  Further,  these  data  must  be  stored 
such  that  they  can  be  displayed  on  a  variety  of  computer  systems  without  change.  In  addition,  it 
would  be  desirable  to  be  able  to  produce  printed  copies  of  the  data  from  the  same  data  base.  Wifh 
these  requirements  in  mind,  an  analysis  was  made  of  technical  data  requirements,  data  base 
management  techniques,  and  data  coding  techniques.  A  data  coding  scheme  and  data  base 
management  approach  were  then  developed  to  meet  these  requirements.  The  APS  was  then 
developed  to  provide  a  means  of  efficiently  creating  the  data,  presenting  the  data  on  a  variety  of 
computer  systems,  and  printing  these  data  according  to  specified  formats  without  changing  the  data 
base.  The  data  base  developed  using  the  APS  is  known  as  a  neutral  data  base,  inasmuch  as  it  does 
not  contain  format  information  and  is  independent  of  the  computer  system  that  will  be  used  to 
display  the  data. 

The  resulting  data  base  coniains  the  technical  data  to  he  displayed  to  the  user.  The  control 
<-odes  used  to  display  the  data  are  inserted  by  a  software  package  called  DataLoad,  which  is 
specific  to  the  output  device  to  be  used.  DataLoad  puts  small  amounts  of  formatting  information 
into  the  data  and  checks  the  data  for  internal  consistency.  The  data  are  then  ready  for  display  on 
the  designated  output  device  using  a  version  of  the  APS  presentation  software  that  has  been 
adapted  for  that  device  (only  relatively  minor  modifications  to  the  presentation  software,  for  the 
screen  and  keyboard  functions,  are  required  to  adapt  it  to  a  particular  output  device). 
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The  APS  project  addresses  three  areas  important  to  the  success  of  the  full  IMIS: 

1.  A  data  base  structure  capable  of  representing  the  complex  data  relationships  found  in 
digital  maintenance  information  created  for  interactive  use. 

2.  Authoring  system  software  to  reduce  the  time  and  effort  required  to  design  and  produce 
the  data. 

3.  Presentation  system  software  to  provide  access  to,  and  interact  with,  the  information 
contained  in  the  data  base. 

The  data  base  used  by  the  authoring  system  of  APS  provides  the  flexibility  required  to 
represent  any  type  of  document,  including  the  complex  interrelated  data  found  in  technical  orders 
(TOs).  The  data  base  may  contain  TOs  written  for  many  types  of  weapon  systems  and  many 
configurations  of  a  weapon  system.  The  basic  structure  of  the  data  in  the  APS  data  base  is  a 
hierarchical  tree.  At  each  node  of  the  tree  is  a  paragraph  of  technical  information.  Supporting 
information  such  as  tables,  graphics,  or  cautions  are  attached  to  the  paragraph  by  the  author 
through  simple  commands.  APS  maintains  the  relationship  of  each  paragraph  with  its  neighboring 
paragraphs,  and  each  paragraph  knows  where  it  fits  into  the  hierarchy.  This  relational  tree 
structure  allows  the  presentation  of  information  to  be  tailored  to  the  needs  of  the  user.  The 
authoring  and  presentation  system  is  described  in  detail  in  Section  II. 


Maintenance  Diagnostic  Aiding  System 

A  critical  function  of  the  IMIS  will  be  to  provide  the  maintenance  technician  with  intelligent 
diagnostic  advice  to  aid  the  technician  in  the  troubleshooting  of  sophisticated  weapon  systems.  In 
1983,  AFHRL  began  an  effort  to  develop  and  advance  technology  to  generate  diagnostics  advice 
using  a  small,  portable  computer.  This  research  led  to  the  development  of  the  Maintenance 
Diagnostic  Aiding  System  (MDAS).  The  MDAS  provided  the  basis  for  the  diagnostic  module  used 
in  the  IMIS-DM. 

The  MDAS  provides  a  wide  range  of  recommended  actions  and  information  to  assist  the 
technician  in  selecting  an  efficient  sequence  of  tests  and  maintenance  actions  to  rapidly  repair  the 
system.  The  MDAS  was  designed  to  work  efficiently  in  an  on-equipment  maintenance 
environment  where  the  technician's  job  is  to  isolate  problems  to  a  replaceable  component  level 
rather  than  to  the  lowest  level  at  which  a  failure  might  occur.  However,  MDAS  will  work  equally 
well  at  the  intermediate  and  depot  levels  of  maintenance  with  appropriate  adjustments  to  the  data 
base. 


MDAS  uses  algorithms  to  identify  the  test  and  repair  activity  sequence  most  likely  to  result 
in  a  repaired  system  in  the  minimum  amount  of  time.  The  algorithms  recommend  the  best  next 
action  based  upon  several  parameters  including  the  likelihood  of  component  failures,  and  task  or 
test  accomplishment  times.  The  diagnostic  module  determines  the  next  recommended  action 
dynamically  at  each  stage  of  the  diagnostic  session,  rather  than  exhaustively  precalculating  these 
actions  to  establish  a  fixed-sequence  decision  tree.  In  addition,  the  algorithms  provide  the 
technicians  with  lists  of  available  actions  which  might  prove  effective  in  repairing  the  system.  The 
lists  are  rank-ordered  by  calculated  probability  of  success.  The  highest  probability  action  is 
recommended;  however,  the  technician  is  free  to  choose  among  ihc  available  alternatives.  Once  an 
action  is  completed,  the  next  recommended  action  is  calculated  based  upon  the  results  of  the 
previous  action. 


5 


The  algorithms  and  the  data  requirements  developed  for  the  MDAS  were  refined  and  used 
to  deve'op  the  IMIS-DM  used  in  the  IMIS-DD  project.  The  refinements  included  the  incorporation 
of  the  following  capabilities: 

1.  multiple-outcome  (nonbinary)  tests, 

2.  availability  of  resources  on  base, 

3.  ability  to  focus  troubleshooting  on  mission-critical  components, 

4.  calculation  of  estimated  maintenance  time,  and 

5.  training/simulation. 

The  IMIS-DM  is  described  in  detail  in  Section  II. 


IMIS-DD  Demonstration  Approach 

The  IMIS  diagnostic  technology  was  demonstrated  by  having  Air  Force  maintenance 
technicians  use  the  PMA  and  the  IMIS-DM  software  to  troubleshoot  faults  in  an  Air  Force 
weapon  system.  To  accomplish  the  demonstration,  the  following  tasks  were  performed: 

1.  The  Fire  Control  Radar  (FCR)  system  on  the  F- 16  aircraft  was  selected  as  the  testbed. 

2.  Technical  data  were  developed  for  the  FCR  system  using  the  APS.  The  technical  data 
included  diagnostics  data  and  the  maintenance  instructions  needed  to  support  the  diagnostic  tasks. 

3.  Software  was  developed  to  interface  the  PMA  and  the  aircraft's  MDL-STD-1553 
database.  The  software  provided  the  capability  to  initiate  the  FCR  BIT  and  feed  the  results  to  the 
IMIS-DM  for  use  in  determining  the  recommended  diagnostic  strategy. 

4.  The  APS  presentation  software  was  modified  to  incorporate  the  requirements  of  the 
diagnostic  module  and  to  incorporate  improved  human  computer  interface  techniques. 

5.  Representative  malfunctions  in  the  Fire  Control  Radar  were  identified,  and  means  of 
simulating  these  malfunctions  were  identified  for  use  in  the  demonstration. 

6.  Air  Force  technicians  at  Homestead  AFB,  Florida,  used  the  PMA  and  diagnostic 
module  to  diagnose  the  simulated  faults.  Their  performance  was  closely  monitored  by  a  trained 
observer  to  identify  problem  areas  and  to  assess  user  reactions  to  the  system.  In  addition,  the 
technicians  were  asked  to  complete  a  questionnaire  to  give  their  reactions  to  the  system  and 
recommendations  for  making  it  more  effective. 

The  methodology  for  the  demonstration  is  described  in  detail  in  Section  III.  The  findings 
are  provided  in  Section  IV. 
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n.  IMIS-DD  TECHNOLOGIES 


The  IMIS-DD  project  tested  and  applied  several  AFHRL  technological  developments. 
Modifications  were  made  as  necessary  for  extending  these  developments  to  meet  program  needs. 
The  major  developments  used  in  the  project  are  described  in  this  section. 


IMIS  Diagnostic  Module 


Embedded  diagnostics  on  today's  aircraft,  sophisticated  as  these  on-board  diagnostics  are, 
still  suffer  from  high  false  alarm  rates  and  ambiguous  fault  indications.  As  weapon  systems  of  the 
future  become  more  complex,  the  need  for  accurate  diagnostic  data  becomes  more  critical.  Failure 
of  on-board  diagnostics  to  detect  and  isolate  faults  requires  the  technician  to  use  troubleshooting 
tools  external  to  the  aircraft.  The  IMIS-DM  is  one  such  tool  (Cooke,  Jemigan,  Huntington, 

Myers,  Gumienny,  &  Maiorana,  1990;  Cooke,  Jemigan,  Myers,  Maiorana,  Link,  &  Mason, 

1990).  The  IMIS-DM  advises  the  maintenance  technician  as  to  the  best  troubleshooting  strategy  to 
isolate  a  fault  and  repair  a  disabled  aircraft. 

The  IMIS-DM  is  a  computer-based  system  for  providing  intelligent  diagnostic  advice  for 
use  by  maintenance  technicians  to  troubleshoot  problems  in  aircraft  systems.  It  integrates  a  variety 
of  data  (including  design  data,  historical  data,  repair  times,  test  times,  mean  time  between  failure 
data,  and  parts  information)  to  guide  the  technician  in  the  fault  isolation  process.  The  system 
includes  a  sophisticated  algorithm  to  calculate  the  most  efficient  diagnostic  strategy,  which  is  then 
recommended  to  the  technician.  The  technician  has  the  option  of  following  the  recommended 
action  or  selecting  another  action  from  a  list  of  options  provided  by  the  IMIS-DM.  In  addition,  the 
system  provides  the  capability  for  the  technician  to  call  up  a  variety  of  information,  such  as 
historical  data,  to  assist  in  his/her  decision  process. 

A  key  design  feature  of  the  IMIS-DM  algorithms  is  optimization  of  the  repair  and  recovery 
time  of  a  weapon  system  rather  than  time  to  fault  isolation.  This  philosophy  takes  advantage  of 
scenarios  in  which  a  rectification  action  has  a  high  probability  of  repairing  a  fault  faster  than  does 
isolating  a  fault  through  tests  and  then  repairing.  For  example,  if  there  is  a  95%  probability  that  a 
line  replaceable  unit  (LRU)  is  faulty  and  the  time  to  repair  is  short,  then  the  IMIS-DM  would 
recommend  replacing  the  LRU.  On  the  other  hand,  if  an  LRU  has  a  50%  failure  probability  and 
will  take  an  hour  to  replace,  then  the  IMIS-DM  would  recommend  testing  first  to  verify  that  the 
LRU  is  faulty.  The  IMIS-DM  uses  a  split-half  diagnostic  strategy  to  determine  the  best  test  to 
perform.  The  split-half  algorithm  uses  test  result  information  and  testing  times  to  maximize 
information  gained  per  unit  cost.  A  comparison  is  made  between  the  best  test  and  a  dominant 
action  (an  action  with  a  very  high  probability  of  success)  that  would  repair  the  suspected 
component.  This  comparison  is  based  on  the  failure  probability  of  the  suspected  component  and 
the  time  required  to  perform  the  repair  action. 


The  IMIS-DM  diagnostic  decision  logic  is  kept  separate  from  the  weapon-system-specific 
data  to  ensure  applicability  to  any  weapon  system;  this  capability  is  implemented  using  generic 
mathematical  algorithms.  In  order  to  carry  out  a  troubleshooting  strategy,  the  IMIS-DM  requires 
lists  of  faults,  symptoms,  tests,  and  repair  actions  for  a  component  unuei  tesi  at  a  specific  level  of 
maintenance  (organizational,  intermediate,  or  depot)  and  the  interrelationships  between  these  items. 
The  level  of  maintenance  is  stressed  as  the  possible  number  of  faults,  symptoms,  tests,  and  repairs 
at  the  intermediate  and  depot  levels  are  much  greater  than  at  the  organizational  level.  The  IMIS-DM 
creates  a  reachability  matrix  (see  Table  1)  formed  by  mapping  these  parameters  of  the  system  under 
investigation. 
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Table  1.  Reachability  Matrix 


Symptoms 

Fault  Codes 

(Machine) 

Symptom 

Description 

(Human) 

Tests 

Rectification 

Action 

Faults 

FC1 

FC2 

SCI 

SC2 

T1 

T2 

MA 

S 

MA 

S 

1 A 

1 

1 

0 

1 

1 

0 

1 

0 

0 

0 

IB 

0 

0 

1 

0 

1 

0 

0 

0 

0 

0 

2A 

1 

1 

0 

1 

0 

0 

0 

0 

0 

1 

2B 

0 

1 

0 

0 

0 

1 

0 

1 

1 

1 

MA  = 
S  =  $ 

^  AC 

1 

2 

mean  ueiidi  tut?  aouun  /“hjjuoi;. 

>wap  for  "new"  item. 

COMPONENTS 

The  IMIS-DM  recommends  the  best  test  or  repair  action  based  upon  the  most  information 
gained  for  the  cost .2  However,  the  technician  is  not  locked  into  this  recommendation.  The 
technician  is  able  to  control  the  diagnostics  process  by  approving  or  disapproving  the  IMIS-DM 
recommendations.  The  technician  can  rely  on  his  or  her  experience  and  knowledge  to  direct  the 
diagnostics.  The  IMIS-DM  provides  three  ranked  lists  for  the  technician:  (a)  ranked  rectifications, 
(b)  ranked  tests,  and  (c)  interleaved  tests/rectifications.  All  the  actions  presented  will  result  in 
some  useful  information  for  continuing  diagnostics.  The  technician  has  the  option  to  view  the 
ranked  tests  and  rectifications  with  their  associated  fault  probabilities  and  performance  times.  The 
technician  also  has  the  ability  to  query  supply  data,  historical  information,  BIT,  and  other  available 
sources  of  diagnostic  data  to  aid  in  troubleshooting.  Once  the  technician  has  decided  upon  a  course 
of  action,  the  computer  provides  the  necessary  technical  data  to  support  the  choice.  This  built-in 
flexibility  allows  maintenance  technicians  to  call  upon  their  own  knowledge  and  experience  to 
facilitate  recovery  of  the  weapon  system.  This  technician-centered  approach  toward 
troubleshooting  is  highly  preferable  to  the  computer-centered  approach  (see  Figure  1)  for  two 
reasons:  (a)  It  takes  advantage  of  any  unique  information  that  the  technician  may  have  about  the 
existing  situation,  and  (b)  it  serves  as  a  motivator  to  the  technician  by  allowing  use  of  his/her  own 
knowledge. 

The  heart  of  the  IMIS-DD  diagnostics  is  a  fault-based  modeling  scheme  which  models 
components  in  a  particular  system  as  a  collection  of  potential  faults.^  This  approach  uses 


^The  cost  factor  used  for  the  demonstration  was  "time  to  perform  the  action." 

^For  discussion  purposes,  "fault"  is  used  to  represent  potential  causes  of  a  failure  of 
components  or  something  causing  the  need  for  a  maintenance  action.  It  is  recognized  that 
components  are  not  necessarily  faulty;  but  for  simplicity,  they  are  referred  to  as  faults. 
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Computer-Centered  Integration  Technician-Centered  Integration 

Figure  1.  Computer-Centered  Integration  Versus  Technician-Centered  Integration. 


symptoms  to  implicate  a  set  of  suspected  faults,  tests  implicating  or  exonerating  faults,  and  repair 
actions  to  rectify  faults. 

A  multiple-fault  scenario  can  be  tackled  by  the  IMIS-DM  through  fault  manipulation.  Fault 
manipulation  is  based  on  distribution  of  fault  probabilities  for  the  symptoms  being  considered, 
how  the  symptoms  span  the  set  of  faults,  the  lower  probability  of  independent  events  occurring 
simultaneously,  and  the  influence  of  time  required  to  complete  each  possible  action.  Basically,  the 
system  at.acks  multiple  faults  by  identifying  the  potential  faults  and  combinations  of  faults, 
spanning  the  most  symptoms,  then  isolating  and  repairing  the  actual  faults  until  the  symptoms  are 
no  longer  present  and  the  system  passes  a  functional  check.  The  order  in  which  the  faults  are 
isolated  and  repaired  depends  on  the  recommendations  of  the  IMIS-DM.  The  diagnostic 
algorithms  utilize  all  available  information  to  make  these  recommendations. 

A  troubleshooting  session  begins  by  initializing  the  fault/symptom  data  through  manual  or 
automatic  data  entry  of  all  available  information  such  as  BIT  results,  pilot-observed  failures, 
and/or  through  system  health  information  downloaded  from  the  MIL-STD  1553  data  bus  (see 
Figure  2,  Logic  Flow).  During  this  initialization  process,  equipment  and  parts  availability  (updated 
from  a  link  to  the  supply  computer)  can  be  entered,  as  well  as  aircraft  configuration  (e.g.,  model 
type  and  set-up,  such  as  nuclear  or  conventional)  and  critical  fault  information  the  IMIS-DM  will 
use  in  troubleshooting.  Knowing  the  availability  of  equipment  and  parts  enables  the  IMIS-DM  to 
mark  each  action  requiring  the  unavailable  items.  These  actions  will  not  be  recommended  by  the 
IMIS-DM.  Criticality  is  a  term  used  to  designate  some  system  functions  essential  for  operational 
requirements.  All  potential  faults  contained  in  the  critical  components  are  identified  as  critical.  The 
IMIS-DM  searches  for  plausible  faults  (implicated  by  symptoms)  identified  as  critical.  This  set  is 
then  given  special  consideration  in  developing  recommended  actions. 
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Figure  2.  IMIS-DM  Logic  Flow 


With  this  information,  evaluations  for  best  tests  and  rectifications  can  be  determined.  As 
the  main^nance  technician  performs  test  and  repair  actions,  faults  will  be  placed  into  various 
categories.  The  category  depends  on  the  result  of  the  test  or  a  functional  check  conducted  after  the 
repair  action.  The  fault  categories  consist  of  the  following:  (a)  the  Union  set,  containing  all 
possible  faults  for  all  noted  symptoms;  (b)  the  Plausible  set,  containing  faults  currently  under 
examination;  (c)  the  Exculpated  set,  containing  faults  proven  good  by  a  passed  test;  (d)  the  Maybe 
set,  containing  faults  in  combination  with  exculpated  faults  provided  they  are  not  part  of  another 
fault  combination  still  in  the  Plausible  set;  and  (e)  the  Rectified  set,  containing  faults  associated 
with  the  repair  action  (all  the  faults  that  could  possibly  be  fixed  by  performing  that  particular 
action). 


A  graphical  representation  of  each  possible  fault  changing  during  the  diagnostic  process  is 
shown  in  Figure  3.  The  Plausible  set  is  formed  after  initialization.  The  technician  can  proceed 
with  the  actions  the  IMIS-DM  has  recommended,  or  an  action  of  his/her  own  choice,  i  iil. 
objective  of  the  diagnostic  algorithm  is  to  exculpate  all  the  faults  in  the  plausible  set  and  return  no 
symptoms.  If  a  test  is  performed  and  the  outcome  of  that  test  is  a  pass,  the  potential  fault(s)  will  be 
placed  in  the  Exculpated  set.  If  the  outcome  is  a  fail,  the  potential  fault(s)  will  remain  in  the 
Plausible  set.  Whether  the  test  passes  or  fails,  the  IMIS-DM  will  use  the  outcome  information  to 
update  the  fault/symptom  relationships.  If  a  repair  action  is  completed,  a  functional  check  will  be 
performed  to  verify  that  the  repair  has  removed  the  suspected  fault(s).  If  the  functional  check 
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passes,  the  fault  will  be  placed  in  the  Rectified  set.  A  failure  of  the  functional  check  will  update  the 
fault/symptom  relationships  and  keep  the  fault(s)  in  the  Plausible  set.  A  fault  that  is  in  combination 
with  an  exculpated  fault  is  placed  in  the  ‘  laybe  set.  When  the  Plausible  set  becomes  empty  and  the 
failure  has  not  been  resolved,  plausible  faults  from  the  Maybe  and  Rectified  sets  will  be  brought 
back  into  the  Plausible  set  to  continue  diagnostics  until  the  actual  fault(s)  is  found. 

For  a  detailed  description  of  the  IMIS-DM,  see  Cooke,  Jemigan,  Huntington,  et  al.  (1990) 
and  Cooke,  Jernigan,  Myers,  et  al.  (1990). 


Initialization 


Figure  3.  Fault  Representation  Movement. 


Authoring  and  Presentation  System 

Technical  data  for  the  IMIS-DD  project  were  prepared  in  a  neutral  data  format  using  the 
Authoring  and  Presentation  System  developed  by  AFHRL.  APS  was  developed  as  a  part  of 
ongoing  AFHRL  in-house  research  examining  the  technical  issues  of  creating  a  maintenance  data 
base  flexible  enough  to  create  and  present  all  types  of  data  required  for  maintenance.  Key 
requirements  are  to  present  the  data  on  different  computer  systems  and  in  different  formats  without 
having  to  modify  or  reauthor  the  data.  These  data  could  range  from  interactive  training  material  to 
procedural,  graphic 'intensive  job  guides.  The  IMIS-DD  project  was  the  first  test  of  the  APS 
software  on  a  large-scale  basis,  and  was  a  major  test  of  the  software  and  authoring  concepts  upon 
which  it  was  based.  Numerous  changes  were  made  to  the  presentation  portion  of  the  software 
during  the  course  of  the  project  in  order  to  accommodate  the  requirements  of  the  IMIS-DM. 
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The  APS  is  composed  of  three  primary  elements: 

1.  The  data  base,  in  which  the  maintenance  technical  data  are  maintained. 

2.  The  authoring  subsystem,  which  provides  tools  to  help  the  author  create  the  data  in  the 
form  required  for  the  data  base. 

3.  The  presentation  subsystem,  which  extracts  the  data  from  the  data  base  and  presents  the 
data  on  a  specific  computer  system  according  to  specified  formats. 

Each  element  of  the  APS  is  described  briefly  below. 


APS  Data  Base 

The  APS  data  are  maintained  in  a  relational  data  base  designed  specifically  for  this 
application.  The  relational  data  base  provides  the  flexibility  required  to  represent  the  complex, 
interrelated  data  found  in  technical  orders.  The  data  are  organized  in  a  hierarchical  representation 
defining  the  structure  of  the  data  base  and  the  interrelationships  between  the  data  elements.  The 
structure  represents  the  data  elements  in  a  linear,  or  sequential,  format  before  DataLoad  is 
performed.  DataLoad  puts  the  data  into  a  tree  format  for  easy  access;  each  node  of  the  tree 
represents  an  element  of  the  data.  Each  node  may  contain: 

1.  the  data,  or  the  location  of  the  data  if  the  data  are  already  stored  elsewhere  in  the  data 

base. 


2.  codes  indicating  the  relationships  of  the  element  to  other  elements  in  the  data.  In 
addition,  they  may  identify  related  information  (such  as  theory  of  operation  or  parts  information) 
the  user  may  wish  to  access. 

3.  various  attributes  of  the  data  element  including: 

a.  verification  Status  -  the  identification  of  whether  or  not  the  data  element  has  been 

verified. 


b.  weapon  Configuration  -  a  code  identifying  the  particular  configuration  or  model  of 
the  aircraft  system  to  which  the  data  are  applicable. 

c.  version  -  the  version  of  the  technical  text. 

d.  track  Level  -  the  skill  level  of  the  intended  user  (novice,  journeyman,  expert,  etc.). 

e.  security  classification  of  the  information. 

The  data  base  is  designed  to  eliminate  redundancies.  This  makes  it  possible  to  use  the  same 
text  or  graphic  material  multiple  times,  but  store  it  only  once  in  the  data  base.  For  example,  an 
illustration  which  is  used  in  many  different  procedures  is  stored  only  once. 


Authoring  Subsystem 

The  authoring  subsystem  is  a  tool  to  assist  the  author  in  creating  data  in  the  form  required 
for  the  APS  data  base.  The  APS  Authoring  software  (APSAuthor)  provides  the  technical  writer 
with  a  word  processor  interface  and  authoring  tools  required  to  create  the  data.  APSAuthor 
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provides  word  processor  functions  to  assist  the  author  in  linking  the  data  elements  created  to  other 
related  data  elements.  Word  processor  functions  include  (a)  automatic  indention  and  paragraph 
numbering,  (b)  word  wrap,  (c)  insert  and  overwrite  text,  and  (d)  block  manipulations  to  copy  and 
cut-and-paste  information. 

APSAuthor  provides  tools  to  assist  the  author  in  linking  data  elements  and  graphics 
together.  Data  elements  are  linked  automatically  when  specifically  created  to  go  together.  For 
example,  when  a  warning  is  created  to  support  a  specific  step  in  a  procedure,  the  warning  is 
automatically  linked  to  that  step.  If  a  step  is  to  be  linked  to  a  previously  created  data  element  or 
graphic,  the  system  provides  a  menu  of  data  elements  from  which  the  author  may  select.  When  the 
author  makes  a  selection  from  the  menu,  the  data  elements  are  automatically  linked.  When  a  link  is 
created,  the  locations  of  the  linked  data  are  automatically  recorded  as  part  of  the  data  element. 

The  tools  provided  by  APSAuthor  greatly  simplify  the  writer's  task.  He  or  she  does  not 
have  to  keep  track  of  the  location  of  the  data  elements,  nor  enter  the  complex  codes  required  to 
index  the  data  for  later  extraction  from  the  data  base.  The  writer  can  focus  on  creating  complete 
and  accurate  technical  data.  The  writer  never  has  to  worry  about  determining  font  sizes, 
positioning  data  on  the  screen,  or  making  color  choices.  The  technical  writer  need  be  concerned 
only  with  maintenance  instructions  and  complete  identification  of  supporting  material. 


Presentation  Subsystem  APSPresent 

APSPresent  is  a  program  written  to  retrieve  technical  data  from  the  APS  relational  data  base 
and  present  it  to  technicians  for  flight  line  maintenance.  It  is  a  flexible  tool  that  AFHRL 
implemented  to  evaluate  the  relationship  of  selected  functions  and  screen  interfaces  with  the  overall 
acceptance  by  maintenance  technicians,  as  well  as  the  benefits  of  electronic  maintenance  aids  to  the 
maintenance  community.  It  also  allows  researchers  to  evaluate  the  validity  of  the  APS  data  base 
design  and  to  develop  guidelines  describing  the  best  methods  to  construct  and  author  technical  data 
using  APSAuthor. 

One  of  the  objectives  of  the  APS  was  to  demonstrate  that  neutral  data  can  be  presented  on  a 
variety  of  different  computer  systems  without  modification  to  the  data.  To  meet  this  objective,  the 
APSPresent  was  designed  to  be  very  flexible.  This  was  accomplished  by  a  modular  software 
design  and  the  use  of  a  common  programming  language  (C).  The  software  can  be  adapted  for  use 
on  other  hardware  systems  by  modifying  the  appropriate  modules  to  incorporate  the  relevant 
features  of  the  new  system  (e.g.,  screen  size,  shape,  resolution)  and  any  special  formatting  rules  to 
govern  presentation  of  tire  data.  Versions  of  APSPresent  have  been  developed  for  the  PCMAS  I, 
PCMAS  II,  Sun  workstation,  and  MSDOS-based  personal  computers. 

APSPresent  retrieves  data  from  the  APS  relational  data  base  and,  basing  its  decision  on  the 
content  of  the  information,  dynamically  decides  how  to  display  the  data.  The  rules  used  are  based 
upon  the  results  of  previous  AFHRL  research. 

The  first  task  of  APSPresent  is  to  allow  the  user  to  select  information  to  be  displayed.  To 
do  this,  APSPresent  must  evaluate  the  user's  answers  to  questions,  consider  his/her  level  of 
expertise,  cross-reference  the  weapon  configuration,  and  bring  up  the  correct  version.  The 
program  must  also  know  what  steps  have  been  seen  by  the  technician.  APSPresent  can  display  the 
nCAi  bit  of  information  or  what  was  previously  seen,  based  on  track  and  configuration  attributes. 
APSPresent  can  also  create  a  menu  for  the  table  of  contents  in  order  to  allow  the  technician  access 
to  any  available  procedure. 
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Once  a  selection  has  been  made,  APSPresent  must  decide  how  to  display  the  information. 
Functional  specifications  and  formatting  rules  developed  by  human  factors  engineers  are  used  to 
assemble  and  present  the  interactive  technical  maintenance  information. 

Other  presentation  programs  could  read  the  same  data  base  and  display  the  data  in  a 
completely  different  way,  based  upon  entirely  different  rules.  With  this  type  of  presentation 
system,  the  data  need  not  change  as  the  presentation  rules  change. 


Portable  Maintenance  Aid  (PMA1 

A  major  element  of  the  overall  IMIS-DD  program  is  a  small  portable  computer  capable  of 
presenting  text  and  complex  graphics  to  the  aircraft  maintenance  technician.  Two  prototype 
portable  computers  were  designed  specifically  for  use  in  research  to  develop  techniques  for 
automated  presentation  of  technical  information  for  use  on  the  flight  line.  They  were  PCMAS  I 
and  the  preplanned  product  improvement  version,  PCMAS  II.  The  PCMAS  II  was  adopted  as  the 
PMA  for  the  IMIS-DD  project.  PCMAS  I  and  PCMAS  II  are  described  briefly  below. 


PCMAS  I 

PCMAS  I  was  AFHRL's  initial  in-house  attempt  at  designing  a  portable  computer  to 
present  automated  technical  data  to  maintenance  technicians  in  an  on-equipment  environment.  It 
served  as  a  research  tool  for  testing  the  various  hardware  and  software  aspects  important  to  the  full 
IMIS  development.  It  helped  establish  information  requirements  for  an  operational  portable 
system.  PCMAS  I  was  based  upon  an  earlier  design  developed  by  Boeing  Military  Airplane 
Company  under  contract  with  AFHRL. 

PCMAS  I  features  the  Motorola  68010  microprocessor  with  2.5  megabytes  of  internal 
memory  and  a  removable  memory  cartridge  of  1  megabyte  of  non-volatile  memory.  It  uses  an 
electroluminescent  display  with  high  resolution  (72  dots  per  inch).  It  has  the  capability  to  run  on 
an  external  battery  pack,  aircraft  power,  or  standard  1 10V  AC  power.  Two  ports  allow  the  device 
to  interface  with  peripherals  in  the  shop  (RS-232)  and  the  MIL-STD-1553  aircraft  data  bus. 
PCMAS  I  uses  the  UNIX  operating  system.  It  also  has  the  capability  to  present  multiple  windows 
of  data. 


PCMAS  I  was  used  in  a  preliminary  test  to  demonstrate  the  use  of  a  portable  computer  for 
presenting  technical  information  to  maintenance  personnel.  A  small  sample  of  technical  data  was 
developed  for  the  F- 16  Chaff/Flare  Dispenser  System.  Technicians  at  MacDill  AFB,  Florida,  used 
the  technical  data  on  PCMAS  I  to  perform  a  checkout  task  on  the  system.  Test  results  indicated  the 
technicians  could  perform  maintenance  effectively  using  the  system.  However,  the  system 
required  approximately  10  seconds  to  present  a  frame  of  graphics  and  text.  This  was  judged  to  be 
too  slow  in  presenting  instructions  to  satisfactorily  support  maintenance  operations.  Technicians 
participating  in  the  study  had  a  positive  reaction  to  the  system  but  indicated  that  it  was  too  slow  for 
use  in  their  regular  work.  Several  other  weaknesses  were  identified:  (a)  The  battery  capacity  was 
inadequate  (maximum  of  1  hour),  (b)  the  display  was  not  readable  in  direct  sunlight,  and  (c)  the 
capacity  of  the  memory  cartridge  was  very  limited. 


PCMAS  II 

PCMAS  II  was  developed  to  provide  a  system  without  the  problems  identified  in  PCMAS 
I.  PCMAS  II  was  used  as  the  PMA  for  the  IMIS-DD  project  (see  Figure  4).  It  was  fabricated 
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from  an  AFHRL  design  based  on  the  Motorola  68020  microprocessor.  It  has  up  to  7  megabytes  of 
memory  (4  megabytes  of  internal  memory  and  3  megabytes  from  a  non-volatile  removable 
cartridge).  The  operating  system  is  OS-9,  a  single-user  ROM  version  of  UNIX,  which  offers  the 
functional  requirements  needed  without  the  software  overhead  costs  of  the  full  implementation  of 
multiuser  UNIX.  Power  requirements  were  greatly  reduced  by  using  a  Liquid  Crystal  Display 
(LCD)  active  matrix  screen  instead  of  an  electroluminescent  display.  The  LCD  active  matrix  screen 
gives  high  resolution  (81  dots  per  inch)  at  one-tenth  the  power  requirements  of  the  PCMAS  I 
screen.  Further  power  reductions  come  from  the  use  of  Complementary  Metal  Oxide 
Semiconductor  (CMOS)  circuitry.  In  addition,  the  LCD  tlay  is  readable  under  all  lighting 
conditions  as  it  is  equipped  with  a  backlight  that  the  user  c  i  switch  on  as  needed. 


Figure  4.  PMA  used  for  IMIS  Diagnostics  Demonstration. 


To  reduce  the  number  and  size  of  the  circuit  boards  ins'de  the  unit,  surface  mount 
technology  was  used  in  about  65%  of  the  circuitry.  Integrated  circuit  chips  commonly  come  in  a 
dual  in-line  package  requiring  mounting  through  both  sides  of  a  printed  circuit  board.  The  smaller 
surface  mount  chips  require  mounting  on  one  side  only,  leaving  the  second  side  available  for 
additional  computer  chip  logic. 


III.  METHOD 


Accomplishing  the  goals  of  the  IMIS-DD  project  required  the  coordinated  performance  of 
several  complex  tasks.  The  first  task  was  to  select  the  testbed  system.  Selection  of  the  testbed 
was  necessary  in  order  to  begin  work  in  other  areas.  Once  this  was  completed,  work  began  on  the 
MIL-STD-1553  data  bus  interface,  technical  data  development,  and  modification  of  the  APS 
presentation  software  to  incorporate  IMIS-DM  and  human  computer  interface  requirements.  In 
addition,  evaluation  procedures  were  developed,  test  problems  were  selected,  and  an  evaluation 
plan  was  prepared.  Each  of  these  activities  is  described  below. 


Testbed  Selection 


To  achieve  the  goals  of  the  IMIS-DD  project,  it  was  necessary  to  select  an  aircraft 
subsystem  to  serve  as  a  testbed  for  use  in  testing  the  IMIS-DD  capabilities.  The  testbed  system 
needed  to  meet  the  following  criteria: 
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1.  Be  on  an  aircraft  which  is  equipped  with  a  MIL-STD-1553  data  bus  that  is  controllable 
from  an  external  device,  and  maintains  a  digital  record  that  can  be  downloaded  of  failures  which 
occur  in  flight. 

2.  Be  accessible  through  the  aircraft’s  data  bus. 

3.  Be  sufficiently  complex  to  provide  a  thorough  test  of  the  IMIS-DM  capabilities. 

4.  Be  sufficiently  simple  :o  permit  the  development  of  a  complete  set  of  diagnostic  and 
technical  data  with  available  resources  and  within  the  program  schedule. 

The  F-16  aircraft's  FCR  system  was  selected  as  the  testbed  for  the  demonstration  for 
several  reasons.  First,  the  F-16  is  equipped  with  a  MIL-STD-1553  data  bus  that  can  be  controlled 
from  an  external  device.  The  operational  capability  upgrade  (OCU)  version  of  the  F-16  has  an 
external  connection  located  near  the  right  wing  which  could  be  used  for  connecting  the  portable 
computer  to  the  aircraft.  Second,  the  OCU  version  is  fitted  with  a  data  transfer  unit  (DTU)  which 
contains  a  record  of  the  failures  that  have  occurred  on  the  aircraft  during  flight.  This  fulfills  the 
requirement  to  download  maintenance  data  directly  from  the  aircraft.  The  FCR  system  was 
selected  from  the  F-16  systems  accessed  from  the  data  bus  because  it  is  moderately  complex  and 
would  provide  a  fair  test  of  the  IMIS-DM  capabilities.  Also,  it  was  judged  that  technical  data  for 
the  system  could  be  developed  with  the  available  project  resources.  In  addition,  the  FCR  is  on  the 
"bad  actor"  list  due  to  its  many  maintenance  problems.  The  FCR's  bad  actor  status  would  provide 
a  challenge  for  the  IMIS-DM  and  provide  face  validity  for  the  evaluation. 


Development  of.Diagnostic  and  Maintenance  Data 

Two  types  of  data  were  created  for  the  demonstration:  (a)  the  diagnostic  data  and  (b)  non¬ 
diagnostic  data  (test  procedures,  removal  instructions,  etc.).  The  diagnostic  data  base  consists 
primarily  of  symptoms,  tests,  faults,  and  rectifications.  These  were  entered  into  the  data  base 
using  APS  in  the  table  form  needed  by  the  IMIS-DM  software.  The  non-diagnostic  data  base 
consists  of  the  text  and  graphic  materials  necessary  to  perform  various  tasks  such  as  directions  to 
open  a  hatch  cover  and  remove  an  LRU.  This  material  was  also  authored  using  the  APS. 

The  authoring  task  gathered  raw  data  from  the  following  sources: 

1.  Technical  Manual  TO  1F-16A-2-94FI-00-1,  Fault  Isolation  Weapons  System  (USAF, 
1987).  This  TO  is  commonly  called  the  94FI  by  the  maintenance  technicians. 

2.  The  set  of  Job  Guides  referenced  by  the  94FI. 

3.  Subject-matter  experts,  General  Dynamics  Fort  Worth  (GDFW)  engineers,  Air  Force 
technicians  of  the  388th  Tactical  Fighter  Wing  (TFW)  at  Hill  AFB,  Utah,  and  the  31st  Aircraft 
Generation  Squadron  (AGS)  at  Homestead  AFB. 

The  fault  isolation  manual  (94FI)  is  a  three-volume  set,  800  pages  each,  containing 
diagnostic  data  for  all  10  of  the  F-16  avionics  subsystems.  The  data  pertaining  to  the  FCR  consist 
of  approximately  500  pages  of  text,  tables,  line  drawings  of  various  views  of  the  aircraft  and 
equipment,  and  schematics  for  the  inter-LRU  wiring. 

Each  subsystem  section  is  divided  into  two  major  parts:  (a)  a  fault  matrix  and  narrative 
relating  fault  codes  from  the  aircraft  to  instructions  for  removing  and  replacing  the  faulty  LRU,  and 
(b)  a  set  of  wiring  diagrams  and  schematics.  Normally,  the  matrix  and  narrative  are  used  to 
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resolve  the  failure  to  an  LRU  or  to  a  group  of  components;  the  wiring  diagrams  and  schematics  are 
used  when  the  matrix  and  narrative  fail  to  lead  to  a  correct  resolution  of  the  problem. 

Initially,  the  creation  of  the  data  base  seemed  to  be  simply  a  matter  of  transposing  the  fault 
matrix  and  narrative  text  into  a  form  suitable  for  use  by  the  IMIS -I'M  and  presentation  by  APS. 
However,  it  became  apparent  that  the  fault  matrix  is  structured  diff  rently  than  what  is  required  for 
MDAS  and  APS.  For  example,  many  logical  loops  are  written  intc  the  text  which  a  human  might 
be  expected  to  "read  through"  and  continue  with  the  task,  but  MD  \S  could  not.  To  implement  the 
same  logic  under  MDAS  required  that  these  loops  be  pulled  apart  and  reassembled  without  the 
inconsistencies. 

It  was  assumed  the  level  of  detail  contained  in  the  text  was  sufficient  to  create  the  "novice 
track"  and  that  the  "expert  track"  could  then  be  a  condensation  of  the  more  complete  novice  track. 
However,  the  level  of  detail  in  the  data  for  the  diagnostic  presentation  is  inconsistent,  leaning 
heavily  toward  the  expert  track.  When  more  detail  was  needed  to  Fill  in  for  the  novice  track,  a 
detailed  analysis  of  the  subsystem  was  conducted  to  obtain  the  necessary  information. 

As  in  the  fault  isolation  manual,  the  Job  Guides  (JGs)  contained  logical  inconsistencies  a 
human  reader  might  not  notice  but  which  had  to  be  resolved  for  presentation  on  the  PMA.  For 
example,  because  the  JGs  were  written  as  general  directions  for  tasks  called  for  in  the  94FI,  they 
had  to  be  written  in  general  form.  If  an  aircraft  panel  required  removal,  the  JG  gave  directions  to 
remove  it.  However,  directions  to  remove  that  same  panel  might  have  already  been  given  in  the 
94FI  instructions,  resulting  in  a  literal  translation  of  the  direct)  is  to  remove  the  same  panel  twice. 
This  type  of  problem  caused  great  difficulty  in  creating  the  data  i.  ase. 

The  IMIS-DM  software  requires  a  great  deal  of  information  to  properly  analyze  the 
malfunctions  encountered.  These  data  were  created  for  IMIS-DD  using  features  of  the  APS  to 
enter  the  data  into  a  series  of  18  tables.  Six  of  these  tables  contain  information  about  basic  aircraft 
element  systems,  symptoms,  tests,  rectifications,  faults,  and  access  groups.  Five  tables  define  the 
mapping  among  elements  of  the  basic  tables.  The  remaining  tables  define  the  operation  on  the 
MIL-STD-1553  bus  connection  to  the  aircraft. 

The  18  data  tables  constructed  were  as  follows: 

1 .  System  Table  -  The  System  Table  contains  a  unique  system  identifier  and  a  short  text 
field  that  defines  the  system.  For  example,  FCR  would  be  the  system,  and  the  description  would 
be  "Fire  Control  Radar." 


2.  Symptoms  Table  -  This  table  identifies  and  describes  symptoms  to  be  diagnosed  that 
can  be  either  observed  by  the  pilot  or  recorded  in  the  Maintenance  Fault  List  (MFL)  on  the  data 
transfer  unit.  Each  possible  symptom  that  can  be  diagnosed  is  entered  in  this  table.  It  contains 
three  columns:  (a)  Symptom  ID,  (b)  Description,  and  (c)  Intermittent  ID.  The  Symptom  ID  is  a 
simple  6-digit  alphanumeric  code  similar  to  an  MFL  that  defines  the  symptom  (e.g.,  SMS-001). 
The  second  column,  "Description,"  contains  a  text  description  of  the  symptom;  the  last  column, 
"Intermittent,"  indicates  the  symptom  has  been  designated  as  either  intermittent  or  not  intermittent. 


An  intermittent  symptom  is  a  failure  indication  that  occurs  during  aircraft  operation 
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duplicated  or  noticed  duuug  iiiUiiiiciiaiiot. 
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3.  Tests  Table  -  This  table  identifies  and  describes  tests  that  are  used  to  check  the  status  of 
the  potential  faults  on  the  aircraft.  It  identifies  the  rectification  action  and  contains  a  description  of 
the  test,  the  number  of  possible  outcomes,  and  the  time  required. 
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4.  Rectification  Table  -  This  table  identifies  and  describes  rectifications  that  are  used  to 
correct  the  potential  faults  on  the  aircraft,  it  identifies  the  rectifications,  the  repair  level,  the  Mean 
Time  Between  Failure  (MTBF),  and  the  location  of  the  text  data. 

5.  Faults  Table  -  The  Faults  Table  identifies  the  potential  faults  that  require  rectification.  It 
identifies  each  fault  and  contains  a  text  description  of  the  fault  and  its  MTBF. 

6.  Access  Groups  Table  -  This  table  describes  the  doors,  panels,  and  skins  on  the  aircraft 
that  must  be  opened  or  removed  to  perform  maintenance.  It  also  contains  the  time  needed  for  each 
operation. 

7.  System  Mappings  Table  -  This  table  associates  symptoms,  tests,  rectifications,  faults, 
and  access  groups  of  each  system.  Each  field  either  holds  a  unique  identifier  or  is  blank.  Each 
System,  Symptoms,  Tests,  Rectification,  Faults,  and  Access  Group  table  has  a  corresponding 
identifier  in  the  basic  data  tables,  and  vice  versa.  For  example,  no  fault  identifier  can  be  listed  in 
the  System  Mappings  Table  and  not  in  the  Faults  Table;  nor  can  a  fault  identifier  be  listed  in  the 
Faults  Table  and  not  in  the  System  Mappings  Table. 

8.  Access  Group  Mappings  Table  -  This  table  lists  all  the  tests  and  rectifications  of  each 
access  group.  It  relates  access  groups  to  tests  and  rectifications  in  a  manner  similar  to  the  System 
Mappings  Table.  Each  field  either  holds  a  unique  identifier  or  is  blank.  Each  identifier  must  be 
unique,  not  only  within  its  own  group  but  among  all  groups.  Each  test  and  rectification  must  have 
a  corresponding  identifier  in  the  basic  data  tables,  and  vice  versa.  For  example,  no  test  identifier 
can  be  listed  in  the  Access  Group  Mappings  Table  and  not  in  the  Tests  Table. 

9.  Symptoms-to-Faults  Table  -  This  table  lists  the  implicated  faults  of  each  symptom,  as 
well  as  the  relative  probability  of  each  fault. 

10.  Tests-to-Faults  Table  -  The  Tests-to-Faults  Table  lists  the  implicated  faults  of  each  test. 
It  contains  the  test  ID,  outcome  indicator,  and  fault  identifier. 

1 1 .  Rectifications-to-Faults  Table  -  The  Rectifications-to-Faults  table  lists  the  implicated 
faults  of  each  rectification. 

12.  Configurations  Table  -  This  table  is  used  to  control  testing  of  the  various 
configurations  of  the  weapon  system  under  test.  It  describes  the  configuration  item  (radio,  etc.), 
the  various  configurations  of  the  item,  the  associated  LRUs  involved,  and  the  valid  symptoms. 

13.  Criticalities  Table  -  This  table  identifies  mission  critical  configurations  to  be  used  with 
the  Criticalities  Mappings  Table. 

14.  Criticalities  Mappings  Table  -  This  table  identifies  and  cross-references  mission  critical 
configurations  to  the  faults. 

15.  Test  Equipment  Table  -  This  table  identifies  special  equipment  used  during 
maintenance. 

16.  Equipment  Mappings  Table  -  This  table  maps  the  equipment  used  to  the  tests  that 
require  the  equipment. 

17.  Automatic  Test  Command  Table  -  This  table  is  used  to  identify  those  tests  which  can 
be  performed  automatically  (using  the  BIT  on  the  weapon  system)  and  contains  associated 
parameters  required  to  obtain  the  test  results  over  the  MIL-STD-1553  data  bus. 
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18.  1553  Command  Masks  Table  -  This  table  contains  a  series  of  masks  needed  to  transmit 
the  1553  data  bus  commands  to  the  subsystem  under  test. 


Test  Problem  Selection 

During  the  weeks  preceding  the  formal  demonstration,  the  list  of  proposed  faults  (see 
Appendix  A)  was  examined  to  verify  which  faults  were  feasible  to  simulate  and,  of  those,  which 
were  adequately  treated  by  the  MDAS  data  base.  Because  the  demonstration  was  not  planned  to  be 
a  rigorous,  carefully  controlled  formal  experiment,  and  because  the  data  base  was  not  100% 
complete, 4  it  was  necessary  to  select  a  set  of  faults  for  which  the  data  base  contained  sufficient 
guidance  to  lead  the  subjects  through  to  complete  solutions  of  troubleshooting  problems. 

After  a  detailed  review  of  the  original  list  of  proposed  faults,  a  set  of  six  was  selected  for 
the  2-week  demonstration.  A  scenario  was  developed  for  each  demonstration  problem.  The 
scenarios  included: 

1.  a  statement  of  the  means  by  which  the  demonstration  team  could  physically  simulate  the 
fault  in  the  aircraft  (broken  cable,  bad  relay,  etc.). 

2.  the  MFL  number  reported  by  the  aircraft's  BIT  following  insertion  of  the  bad 
component. 

3.  a  rank-ordered  list  of  the  "top  five"  actions  recommended  by  the  IMIS-DM  to  begin 
troubleshooting  the  reported  MFL. 

4.  a  listing  of  the  steps  the  subject  would  be  expected  to  follow  if  he/she  accepts  all  of  the 
computer's  recommendations. 

The  six  problems  selected  for  use  in  the  evaluation,  along  with  their  corresponding  MFL 
numbers,  are  shown  in  Table  2. 

Two  additional  problems  were  planned.  Each  problem  was  a  combination  of  two  of  the 
faults  listed  above  inserted  into  the  aircraft  at  the  same  time.  The  first  combined  MFLs  033  and 
595;  the  second  combined  MFLs  340  and  595.  The  IMIS-DM  resolved  these  multiple  (but 
independent)  faults  by  sequentially  diagnosing  them,  having  them  fixed,  and  rerunning  the 
aircraft's  BIT  to  see  if  any  faults  remained.  5 


4  Diagnostic  data  for  all  known  faults  were  included  in  the  data  base  for  all  known  faults. 
However,  all  required  supporting  data  (job  guides,  graphics,  etc.)  were  not  available  for  some 
faults. 

5  The  033/595  fault  was  the  fourth  problem  tackled  by  the  first  pair  of  subjects.  It  involved 
opening  a  waveguide  (the  simulated  033  fault)  and  resulted  in  the  need  to  conduct  a  waveguide 
pressurization  test  before  the  task  could  be  considered  complete.  A  problem  arose  with  this 
procedure;  the  waveguide  pressurization  tester  that  was  immediately  available  within  the  Aircraft 
Maintenance  Unit  (AMU)  for  support  of  the  demonstration  was  not  the  kind  for  which  the  IMIS- 
DD  data  base  procedure  was  written.  A  further  problem  was  that  the  small  ultrasonic  leak  tester  to 
be  used  in  conjunction  with  the  pressurization  test  appeared  not  to  be  working  properly.  These 
two  difficulties  made  the  use  of  the  033  problem,  either  by  itself  or  combined  with  MFL  595, 
undesirable  for  the  demonstration  because  the  subjects  were  unable  to  conduct  a  reliable 
pressurization  test.  The  study  team  elected  to  discontinue  the  use  of  either  problem  containing 
MFL  033. 
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Table  2  Simulation  of  Faults 


MFL 

How  Simulated 

033 

Open  the  Schrader  valve  at  the  LPRF 
(simulates  a  leak  in  the  waveguide) 

319 

Disconnect  the  hardline  cable  between  the 
transmitter  and  the  LPRF 

340 

Insert  a  bad  K1  relay  or  pop  circuit 
breaker 

400 

Install  a  dummy  cable  at  the  DSP  or  LPRF 

572 

Disconnect  the  throttle  grip  cannon  plug 
(simulates  a  bad  throttle-grip) 

595 

Install  a  dummy  cable  between  the  LPRF 
and  the  Fire  Control  Computer  (FCC) 

Evaluation  Approach 

The  IMIS  diagnostic  capability  was  evaluated  by  having  Air  Force  technicians  at 
Homestead  AFB,  Florida,  use  die  PMA  and  the  IMIS-DM  to  isolate  faults  inserted  into  the  FCR  on 
the  F-16  aircraft.  Their  performance  was  monitored  by  an  experienced  observer.  After  the 
problems  were  executed,  the  technicians  completed  a  questionnaire  designed  to  obtain  their 
reactions  to  using  the  system  and  to  solicit  suggestions  for  improving  the  system. 


Subjects 

The  subjects  used  in  the  demonstration  were  personnel  provided  by  the  308th  and  309th 
Aircraft  Maintenance  Units  (AMUs)  of  the  31st  Tactical  Fighter  Wing  at  Homestead  AFB,  Florida. 
Twelve  subjects  were  used  over  the  2-week  demonstration  period  that  began  on  Monday,  8  May 
1989,  and  ended  on  Friday,  19  May  1989. 

Selected  biographical  information  was  collected  from  each  of  the  subjects.  In  addition  to 
rank  and  Air  Force  Specialty  Code  (AFSC),  each  subject  was  asked  to  report  the  length  of  time  he 
had  been  in  the  Air  Force,  in  his  present  specialty,  and  in  the  Tactical  Air  Command  (TAC).  He 
was  also  asked  how  much  time  he  had  spent  working  on  the  F-16  A,  B,  C,  and  D  models,  how 
much  time  on  the  F  16  radar  system,  and  how  much  time  on  other  aircraft  besides  the  F-16.  The 
career  status  and  biographical  information  for  the  subjects  are  summarized  inTables  3  and  4, 
respectively.  All  12  subjects  possessed  the  452X2  AFSC.  Eight  reported  being  in  the  452X2A 
Air  Force  Specialty  (AFS)  (the  A  suffix  denotes  "A-shoppers,"  whose  responsibilities  include  the 
fire  control  radar);  two  of  the  subjects  reported  being  in  the  452X2B  AFS  (the  B  suffix  denotes 
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Specialties  and  Skill  Levels  of  Demonstration  Subjects 


Specialty  Code 

1  452X2A 

452X2B 

452X2 

Skill 

Level 

Rank 

3 

SSgt 

5 

SRA 

5 

A1C 

5 

A1C 

3 

A1C 

3 

Sgt 

3 

SRA 

3 

A1C 

3 

Amn 

3 

A1C 

3 

A1C 

7 

MSgt 

Biographical  Data  for  Demonstration  Subjects 


Mean 


Time  (In  Months) 

AF 

Specialty 

TAC 

A/B 

C/D 

F-16  Radar 

66 

12 

48 

12 

0 

12 

36 

38 

2 

2 

26 

28 

27 

27 

27 

27 

0 

27 

36 

36 

36 

36 

0 

36 

13 

13 

13 

13 

0 

13 

53 

5 

5 

18 

12 

5 

48 

36 

48 

12 

0 

12 

17 

17 

17 

17 

0 

17 

14 

14 

14 

14 

0 

14 

14 

14 

14 

14 

0 

14 

18 

18 

18 

1  0 
•  V 

A 

U 

16 

186 

120 

186 

114 

6 

120 

44.0 

29.0 

IBS! 

24.75 

3.67 

26.3 
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"B-shoppers,"  who  deal  with  the  flight  control  system);  two  reported  no  suffix,  describing 
themselves  only  as  "avionics  specialists."  Eight  of  the  technicians  were  classified  at  the  3  skill- 
level,  three  at  the  5  skill-level,  and  one  at  the  7  skill-level.  Only  three  subjects  reported  experience 
with  other  aircraft  types.  Subject  number  6  reported  18  months  with  T-37s;  subject  number  7 
reported  24  months  with  F  4s;  and  subject  number  12  reported  65  months  with  RF-4Cs,  T-33s, 
and  T-39s. 


Questionnaires 

Two  questionnaires  were  developed  for  gathering  participants'  subjective  impressions  (see 
Appendix  B).  The  first,  called  "IMIS-DD  Task  Debriefing"  (see  Appendix  B),  was  a  brief  series 
of  questions  to  be  administered  upon  completion  of  each  troubleshooting  problem,  while  details  of 
that  problem  were  fresh  in  the  subject’s  mind.  The  second,  called  "IMIS-DD  User  Evaluation 
Questionnaire"  (see  Appendix  B),  was  designed  to  elicit  some  summary  impressions  from  each 
subject  upon  completion  of  all  of  his  assigned  problems. 

The  debriefing  form  was  intended  to  explore  any  difficulties  that  the  subject  might  have 
experienced  during  the  performance  of  each  task.  The  subject  was  asked  to  describe  these 
difficulties  in  as  much  detail  as  possible  (using  the  PMA  to  illustrate  them,  if  necessary),  while  the 
task  was  still  fresh  in  his  mind.  The  form  also  requested  the  subject  to  list  the  good  features  of  the 
PMA  he  had  noted  during  the  task,  and  to  give  suggestions  to  improve  the  PMA  hardware  or 
software.  Each  subject  completed  the  evaluation  questionnaiie  after  he  had  performed  all  of  his 
assigned  problems.  The  subject  was  asked  to  use  a  5-point  scale  to  rate  some  physical  features  of 
the  system  and  the  information  presented  by  the  PMA,  and  to  compare  the  presentation  of  data  on 
the  PMA  with  that  currently  used  in  paper  technical  orders  (TOs.)  The  questionnaire  also  asked 
open-ended  questions  to  elicit  each  subject's  opinions  about  the  level  of  detail,  likes  and  dislikes 
about  the  PMA,  and  potential  implementation  problems.  It  also  requested  suggestions  the  subject 
might  have  for  improving  the  PMA. 


Procedures 


The  subjects  participated  in  the  study  in  pairs.  The  study  team  generally  had  access  to  a 
given  pair  of  subjects  for  at  least  1  full  workday;  some  subjects  were  available  for  approximately 
1.5  workdays. 

Each  pair  of  subjects  began  by  spending  approximately  1  hour  in  a  familiarization/training 
session  with  an  evaluation  team  member.  This  training  period  generally  consisted  of  an 
introduction  to  the  IMIS-DD  project,  a  description  of  the  PMA  and  procedures  for  its  use,  a 
demonstration  of  most  of  its  available  features,  and  a  period  of  approximately  15  minutes  during 
which  the  subjects  could  practice  with  the  PMA. 

While  the  subjects  were  being  introduced  to  the  PMA,  other  members  of  the  study  team 
(assisted  by  a  technician  assigned  by  the  31st  AGS)  ran  the  FCR  BIT  to  verify  that  the  aircraft  did 
not  have  any  faults  that  would  interfere  with  the  planned  test.  The  team  then  inserted  the  first 
chosen  fault  and  ran  the  BIT  again  to  confirm  that  the  proper  MFL  fault  was  reported. 

When  the  subjects  arrived  at  the  test  hangar  following  the  training  period,  they  were  given  a 
PMA  with  the  memory  module  installed  and  were  told  to  begin  troubleshooting  the  aircraft.  If  the 
particular  problem  involved  pilot-reported  faults  in  addition  to  MFLs  reported  by  the  BIT,  the 
subjects  were  given  such  information  verbally  before  beginning  to  troubleshoot. 
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At  various  points  during  each  problem,  electrical  power  had  to  be  applied  to  the  aircraft  to 
allow  it  to  run  the  BIT  on  the  radar.  Because  the  F-16  is  not  designed  to  allow  an  external  device 
such  as  the  PMA  to  run  the  BIT  entirely  from  outside  the  airplane,  it  was  necessary  for  one  of  the 
subjects  to  sit  in  the  cockpit  during  tire  operation  of  the  BIT  to  configure  switches  in  a  way  that 
allowed  the  PMA  to  download  fault  information.  The  other  subject  stayed  on  the  ground  and  read 
a  PMA-displayed  checklist  of  switch  settings  to  the  technician  in  the  cockpit.  During  these 
periods,  the  noise  created  by  a  turbine  powered  generator  and  an  air  conditioning  unit  made  it 
necessary  for  the  subjects  to  communicate  with  each  other  using  the  aircrafts  intercom  via  noise¬ 
cancelling  headsets  and  microphones,  just  as  they  would  on  the  flight  line.  One  of  the  study  team 
members,  the  "designated  observer,"  also  used  the  intercom  at  the  same  time  to  monitor  the 
subjects'  interactions  and  to  be  available  to  answer  questions.  Other  study  team  members  and 
occasional  visitors/observers  were  also  in  the  area  during  the  performance  of  most  tasks,  but  only 
the  observer  with  the  headset  could  monitor  what  die  subjects  said  while  the  generator  was 
running. 

Once  a  pair  of  subjects  had  begun  a  task,  they  were  allowed  to  proceed  on  their  own 
without  interruption,  unless  the  designated  observer  noticed  that  they  had  done  (or  were  about  to 
do)  something  completely  inappropriate.  The  designated  observer  was  allowed  to  answer 
questions  that  the  subjects  asked,  but  he  tried  to  provide  as  little  information  as  possible,  if  he 
believed  die  subjects  could  answer  their  own  questions  using  the  PMA.  The  subjects  needed 
occasional  prompts  to  help  them  recall  the  PMA  features  they  clearly  did  not  remember  from  the 
brief  familiarization/training  session. 

Subjects  proceeded  through  a  task,  interacted  with  the  PMA  (see  Figure  5),  performed 
tests,  and  ran  the  BIT  until  they  had  found  and  corrected  the  fault  (and  confirmed  that  fact  via  the 
BIT).  Upon  completion  of  each  task,  the  subjects  accompanied  die  designated  observer  to  the 
break  room  or  to  a  quiet  comer  of  the  hangar  to  go  through  the  task  debriefing  fonn.  The  observer 
took  notes  during  each  task  on  anything  the  subjects  weie  observed  doing  that  deviated  from  the 
"computer-recommended"  path.  These  notes  were  used  to  stimulate  discussion  during  the 
debriefing.  In  some  cases,  the  subjects  were  unable  to  add  anything  tu  what  was  already  contained 
in  the  observer's  notes.  In  other  cases,  the  subjects  simply  did  not  have  any  problems  to  report, 
and  no  new  ideas  about  the  PMA  had  occulted  to  them  since  the  previous  task.  Consequently,  the 
debriefing  form  was  empty  for  some  tasks. 


Figure  5.  Technician  using  PMA  during  demonstration. 


23 


The  notes  maintained  by  the  observer  during  the  performance  of  each  task  included  the 
problem  number,  identification  of  the  subjects  performing  the  task;  the  date,  time,  and  location  of 
the  task  performance;  and  start  and  finish  times  of  the  task.  As  the  task  progressed,  the  observer 
noted  deviations  from  the  computer-recommended  path,  and  also  any  optional  information  the 
subjects  accessed  during  the  task.  When  the  subjects  encountered  difficulties,  the  observer  noted 
them  and  tried  to  describe  the  nature  of  the  problem. 


Final  Debriefing 

On  the  final  day  of  the  2-week  demonstration,  8  of  the  12  subjects  joined  the  research  team 
for  a  general,  informal  debriefing  session  held  in  a  large  meeting  room  at  the  base  recreation  center. 
Most  of  the  discussion  was  captured  on  videotape.  During  this  session,  comments  and 
observations  were  made  by  both  subjects  and  members  of  the  demonstration  team.  There  was  no 
particular  order  to  the  topics  and  the  discussion  tended  to  be  free  and  open.  Some  of  the  topics 
covered  during  this  session  had  not  been  covered  in  the  questionnaires.  The  principal  reason  for 
holding  the  informal  session  was  to  give  the  subjects  time  to  reflect  on  the  experience  several  days 
following  their  participation. 


IV.  RESULTS 


The  12  subjects  (6  pairs)  performed  a  total  of  21  troubleshooting  problems,  with  an  average 
of  three  tasks  for  each  pair.  AH  troubleshooting  problems  were  successfully  solved.  Specific 
observations,  along  with  the  results  of  the  questionnaires  and  briefings,  are  summarized  below. 
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Table  5  shows  which  problems  were  assigned  to  the  subject  pairs  and  the  order  in  which 
the  problems  were  presented.  Performance  times  for  each  problem  are  given  in  Table  6.  As  the 
performance  of  a  given  task  progressed,  the  observer  took  notes  and  answered  questions  as 
necessary,  but  tried  not  to  intrude  into  the  subject's  process  of  using  the  PMA  and  performing 
tests  and  rectifications  on  the  aircraft.  In  general,  the  subjects  did  not  appear  to  be  uneasy  with 
the  observer  looking  over  their  shoulders,  nor  did  the  presence  of  other  people  in  the  immediate 
area  appear  to  be  particularly  disruptive. 

Table  6  illustrates  that  there  was  relatively  little  variance  in  the  performance  times  for  all 
subject  pairs  who  performed  problems  319, 400,  and  572.  The  time  variances  for  the  other 
problems  were  due  to  the  order  in  which  the  tasks  were  presented,  and  the  level  of  familiarity 
with  the  FCR  system  and  its  related  tasks.  Specific  observations  for  each  problem  are  given 
below.  Appendix  A  lists  the  procedure  for  simulating  each  fault  on  the  aircraft. 
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Problem  319.  This  problem  simulated  a  broken  hard  line  between  the  transmitter  and  the 
LPRF  (low  power  radio  frequency  unit).  The  three  subject  pairs  who  worked  on  this  problem 
were  familiar  with  the  procedures  for  removing  and  installing  these  two  LRUs,  and  they  all  merely 
glanced  at  the  procedures  for  accomplishing  these  tasks. 

All  of  die  subjects  performed  troubleshooting  of  the  fault  essentially  as  the  computer 
recommended.  All  subjects  found  the  broken  hard  line  promptly.  They  ran  a  continuity  check, 
and  were  then  told  to  assume  the  line  was  bad  (r  ^n  though  it  was  not)  and  to  follow  the  PMA 
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Order  of  Problem  Performance 


Problem  (MFL 


340  400  572  595 


1 

3  2 

4 


033/595  595/340 


Performance  Time  in  Minutes 


Problem  (MFL 


1&2 

3&4 

566 

567 
7&8 
9&10 

11&12 


319 

340 

53 

56 

59 

32 

59 

55 

26 

30 

55.7 

40.6 

033/595  595/340 


75 


instructions  for  its  replacement.  They  performed  all  of  the  removal  and  installation  steps  except 
those  that  required  breaking  the  waveguide  and  loosening  the  LRU  mount  bolts.  The  observer  told 
them  to  simulate  those  steps  in  order  to  avoid  having  to  re-torque  the  bolts  and  run  a  waveguide 
pressurization  test.  The  waveguide  pressurization  test  could  not  be  done  because  the  only  available 
ultrasonic  leak  checker  was  broken. 
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Subjects  1  and  2  said  they  felt  a  bit  slowed  down  by  the  PMA  in  contrast  to  the  Job 
Guides,  pointing  out  that  "You  can  go  a  lot  faster  when  you  don't  have  to  follow  the  procedure 
step  by  step.  We  know  the  procedure."  The  implication  was  that  if  they  had  been  "using"  a  Job 
Guide  Manual,  they  would  have  opened  it  but  not  looked  at  it  for  these  procedural  steps. 

Subjects  9  and  10  invariably  paged  past  continued  notes  and  cautions  (longer  than  one 
screen),  rather  than  using  the  down  arrow  to  see  the  rest  of  the  text  because  they  had  already  read 
them  so  many  times  in  the  manuals.  These  individuals  were  quite  puzzled  by  the  graphics  that 
supported  the  replacement  of  the  broken  hard  line.  One  reported  he  had  no  idea  what  the  graphic 
of  the  forward  bulkhead  was  supposed  to  represent.  The  graphic  was  small  and  essentially 
illegible.  Despite  the  poor  graphic,  they  were  able  to  proceed  and  complete  the  task  essentially  "by 
the  book."  Subjects  5  and  7  had  no  difficulties  and  made  no  deviations  from  the  computer’s 
recommended  path. 

Problem  340.  When  presented  by  itself,  this  problem  was  created  twice  by  installing  a  bad  relay 
and  three  times  simply  by  opening  a  circuit  breaker.  Checking  the  circuit  breaker  is  the  first  action 
recommended  by  the  computer  in  response  to  this  MFL  number;  so,  finding  the  problem  tended  to 
be  much  quicker  when  the  circuit  breaker  was  the  only  problem.  This  is  confirmed  by  Table  6, 
which  shows  that  the  first  two  pairs  of  subjects,  who  had  the  bad-relay  fault,  took  roughly  twice  as 
long  to  complete  the  problem  as  did  the  other  three  pairs  of  subjects,  who  had  only  a  popped 
breaker. 


Subjects  1  and  2  essentially  followed  the  computer-recommended  procedure,  including 
replacement  of  the  transmitter,  which  is  a  recommendation  preceding  the  relay  check.  They  later 
said  that  despite  the  outcome  (the  problem  was  really  the  relay),  they  liked  the  logic  of  the 
computer’s  recommendation,  and  that  they  probably  would  have  replaced  the  transmitter  out  on  die 
flight  line  if  they  had  been  troubleshooting  on  their  own,  despite  the  ease  of  checking  the  relay 
because  "relays  never  fail." 

Subjects  3  and  4  looked  at  their  options  several  times  when  they  reached  the  point  at  which 
the  computer  recommended  replacing  the  transmitter.  They  ultimately  decided  to  go  for  the  relay 
on  the  grounds  that  they  had  noticed  it  had  a  blue  plastic  case,  while  all  the  others  had  aluminum 
cases.  They  guessed  the  demonstration  team  was  more  likely  to  have  stuck  in  a  bad  relay  than  to 
have  installed  a  bad  transmitter.  Their  time  is  somewhat  inflated  because  they  dropped  a  small  flat 
washer  that  was  part  of  the  relay’s  attaching  hardware.  The  entire  team  spent  approximately  7 
minutes  crawling  around  on  the  hangar  floor  searching  for  it.  The  remainder  of  the  task  went 
satisfactorily. 


The  last  three  subject  pairs  had  only  to  deal  with  the  opened  circuit  breaker.  The  part  of  the 
PMA  presentation  that  deals  with  checking  the  breaker  is  quite  clumsy,  especially  for  an 
experienced  technician.  All  of  the  subjects  knew  where  the  panel  was,  how  to  open  the  panel,  and 
how  to  check  a  breaker.  However,  the  task  required  them  to  step  through  the  procedure  for 
opening  the  panel;  then  to  follow  the  procedure  for  checking  the  breaker  and  answer  the  question, 
"Is  the  breaker  tripped?";  and  then  to  do  the  procedure  for  resetting  the  breaker.  For  the  more 
experienced  person,  such  a  procedure  probably  should  be  streamlined  by  telling  the  technician  to 
open  the  panel,  check  the  breaker  and  reset  it  if  necessary  (in  this  case,  that  is  always  the  next  step 
if  it  is  tripped),  and  asking  him  whether  he  had  to  reset  it  or  not.  The  answer  to  that  question 
would  satisfy  the  diagnostic  process,  and  the  whole  thing  could  be  presented  in  a  single  step. 
Subjects  9  and  10  commented  that  this  kind  of  clumsiness  could  induce  people  to  use  the  PMA 
improperly.  They  said,  "Experienced  people  know  lots  of  procedures.  They  will  wind  up  doing 
the  job,  then  going  back  through  the  computer  just  to  get  the  data  into  CAMS  (Core  Automated 
Maintenance  System)."  This  problem  is  one  that  could  easily  occur  with  a  neutral  data  base 
because  the  formatting  instructions  are  not  part  of  the  data  but,  instead,  are  in  the  presentation 
system.  'Hie  technical  data  author  does  not  need  to  know  what  procedures  may  occur  given  the 
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result  of  another,  the  presentation  system,  along  with  the  diagnostics,  determines  the  next 
procedure  to  be  presented. 

Before  Subjects  1 1  and  12  ran  the  final  BIT  check  on  this  task,  the  subject  operating  the 
PMA  read  the  switch  settings  to  himself,  but  forgot  to  tell  the  subject  in  the  cockpit  to  recycle  the 
radar,  so,  they  got  the  same  fault  code  again.  The  observer  had  to  point  out  the  omission.  They 
corrected  it  and  the  next  BIT  passed. 

Problem  400.  This  problem  was  created  by  installing  a  dummy  cable  between  the  LPRF 
and  the  DSP  (digital  signal  processor).  Subjects  3  and  4  missed  the  fact  that  the  first  "Input 
Conditions"  screen  before  the  BIT  listed  "power  on  the  aircraft."  There  was  no  procedure 
automatically  presented  by  the  PMA  for  turning  on  the  generator  so,  they  neglected  to  do  it.  When 
this  omission  was  pointed  out  to  them,  they  tried  to  back  up  to  the  input  conditions  screen  to 
confirm  the  condition  for  themselves,  but  the  PMA  did  not  return  to  that  screen  (a  conceptual 
problem  with  the  way  the  BACK  function  was  implemented).  The  session  was  restarted  in  order 
to  step  through  to  that  point  again. 

This  difficulty  is  the  result  of  an  inability  to  include  every  task  available  for  the  FCR 
system.  Several  of  the  tasks  used  in  the  demonstration  have  input  conditions  that  include  a  couple 
of  open  panels  and  power-on  (or  power-off)  of  the  aircraft;  subsequent  screens  present  procedures 
for  opening  the  panels,  but  never  for  starting  or  stopping  the  external  generator.  This  data 
omission  had  not  been  discovered  until  the  demonstration  was  underway.  When  the  problem  was 
first  noticed,  the  team  began  to  point  out  the  problem  during  the  familiarization/training  session. 
This  helped  but  it  did  not  completely  fix  the  problem;  several  individuals  still  made  the  same  error 
even  after  having  it  pointed  out  during  training. 


Subjects  5  and  6,  whose  previous  experience  did  not  include  troubleshooting  wiring 
problems,  had  some  difficulty  in  using  the  correct  nomenclature  to  identify  connectors.  When  they 
had  removed  two  incorrect  connectors,  the  observer  suggested  that  they  try  the  more-detailed  track 
(using  the  "M/L"  key)  to  see  if  the  additional  detail  and  graphics  would  help  them.  They  switched 
tracks  and  were,  then  able  to  identify  the  appropriate  connectors.  They  managed  to  identify  the 
faulty  cable,  but  they  proceeded  on  to  the  BIT  check  without  going  through  the  procedure  to  repair 
the  cable  because  they  hit  NEXT  too  soon  and  were  confused  about  how  to  "back  track."  The 
observer  helped  them  to  back  track. 

Problem  572 .  This  problem  was  created  by  disconnecting  a  cannon  plug  in  the  cable 
leading  to  the  throttle  grip.  All  three  pairs  of  subjects  followed  the  computer's  recommended  path 
to  the  point  of  confirming  a  bad  continuity  check,  but  all  balked  at  the  computer's  recommended 
next  step  of  replacing  the  throttle  grip.  Each  of  the  subject  pairs  had  at  this  point  performed  two  or 
three  previous  problems  using  the  PMA,  and  all  were  eager  to  "second-guess"  the  computer  and  go 
after  something  they  believed  the  demonstration  team  was  more  likely  to  have  done  to  "bug"  the 
aircraft,  such  as  another  wiring  problem  (which  happened  to  be  the  computer's  second 
recommendation  at  that  point).  Subjects  9  and  10  explored  nearly  every  bit  of  optional  information 
available,  looking  for  a  justification  for  their  desire  to  avoid  changing  the  throttle  grip;  the  other 
subjects  simply  decided  that  they  didn't  want  to  change  it,  without  agonizing  over  Lite  decision  to 
countermand  the  computer’s  suggestion.  All  subjects  ultimately  chose  the  option  of  repairing  the 
wiring. 


There  was  no  graphic  or  procedural  assistance  available  within  the  IMIS-DD  data  base  to 
support  locating  and  identifying  the  other  end  of  the  cable  they  wanted  to  repair.  At  this  point,  the 
observers  gave  the  subjects  a  paper  copy  of  a  graphic  that  had  been  created  from  the  TO  showing 
the  location  of  the  other  end  of  the  cable.  The  subjects  used  this  illustration  to  guide  them  to  the 
other  connector.  Subjects  9  and  10  noticed  a  problem,  but  by  the  time  they  had  selected  the  wiring 
repair  option,  they  no  longer  remembered  which  three  wires  had  been  checked  for  continuity  (and 
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were  therefore  car  didates  for  repair).  They  were  no  longer  able  to  back  track  to  the  screen  that 
contained  the  con  Amity  check,  which  identified  those  wires.  If  they  had  actually  had  to  repair  the 
cable,  they  world  not  have  known  how  to  retrieve  that  information  from  the  PMA. 

During  this  and  most  other  tasks,  several  individuals  had  a  problem  interpreting  the  screen 
that  immediately  follows  each  BIT.  When  the  BIT  returns  one  or  more  MFL  numbers,  those 
numbers  are  reported  on  one  line  of  the  screen;  MFLs  (if  any)  that  were  recorded  during  formal 
debriefing  of  the  pilot  are  presented  on  lines  below.  When  the  technicians  have  successfully 
repaired  a  fault  and  BIT  finally  returns  no  MFLs,  the  PMA  concludes  that  the  reported  faults  have 
been  found.  It  simply  leaves  an  empty  line  on  the  screen  where  the  BIT-retumed  MFLs  were 
initially  displayed,  and  it  continues  to  show  the  pilot-reported  MFLs  below  on  their  original  line 
(this  has  since  been  corrected;  instead  of  being  blank,  the  word  "none"  is  now  displayed).  Even 
when  the  BIT  shows  no  faults,  a  user  who  is  not  a  careful  reader  can  easily  overlook  the  blank  line 
and  think  the  screen  is  telling  him  there  is  still  a  fault  being  reported  by  the  system.  After  this 
problem  was  first  noted,  the  demonstration  team  began  to  point  out  the  correct  interpretation  of  the 
screen  during  familiarization/training;  but  some  individuals  still  became  confused  during  the  task 
performance  when  they  reached  this  screen. 


Problem  595.  This  problem  is  produced  by  installing  a  dummy  cable  between  the  FCC  and 
the  LPRF.  Only  two  subject  pairs  did  this  problem  by  itself;  all  other  subject  pairs  encountering 
problem  595  saw  this  fault  in  combination  with  problem  340. 

It  was  on  this  problem  that  a  conceptual  disconnect  was  discovered  between  the  two  level- 
of-detail  tracks.  At  the  point  in  the  "LESS"  (less  detailed)  procedure  where  the  user  is  told  to  do  a 
visual  inspection  of  a  cable  and  repair  it  as  necessary,  if  he  selects  the  "MORE"  track,  he  gets 
detailed  information  about  repair,  but  nothing  on  inspection  which  should  precede  repair.  This  is 
another  example  of  where  the  data  available  to  the  authors  were  not  complete.  Subjects  1  and  2 
actually  began  hunting  for  tools  to  cut  a  connector  off  (part  of  "repair")  before  inspecting  the  cable 
thoroughly  enough  to  discover  that  it  was  a  dummy  because  that  is  what  the  procedure  told  them. 

Subjects  3  and  4  took  substantially  longer  to  do  this  task  than  did  Subjects  1  and  2.  They 
did  not  make  any  major  mistakes;  but  early  in  the  task,  a  senior  officer  stopped  by  to  observe.  His 
presence  appeared  to  unnerve  the  subject  using  the  PMA.  The  subject  began  to  go  past  some 
screens  without  confirming  switch  settings  with  his  partner  in  the  cockpit.  He  began  to  make 
errors  in  reading  portions  of  procedures  aloud,  and  repeated  several  steps  two  and  three  times,  just 
to  get  the  words  right. 

At  one  point,  a  procedural  step  asked  if  the  cable  from  the  PMA  to  the  aircraft  was 
connected.  The  subject  was  puzzled.  He  had  disconnected  the  cable  earlier  in  order  to  move  the 
PMA;  so,  it  was  in  fact  disconnected.  But,  he  suspected  that  the  reason  for  the  question  was  really 
to  get  him  to  connect  the  cable  if  necessary,  even  though  it  did  not  say  so.  He  finally  asked  the 
observer,  who  told  him  his  interpretation  was  correct  -  he  should  connect  the  cable  and  continue. 
This  highlights  the  need  for  the  TO  author  to  think  carefully  about  the  reason  for  an  action,  before 
deciding  how  to  present  an  instruction. 

Problems  033  and  595.  Problem  033  was  produced  by  opening  a  valve  in  the  waveguide, 
simulating  a  leaking  waveguide.  As  mentioned  earlier,  problems  033  and  595  combined  were 
presented  to  one  pair  of  subjects;  but  because  of  problems  with  a  waveguide  pressurization  tester 
and  an  ultrasonic  leak  detector,  the  study  team  decided  that  033  would  not  be  used  again,  either 
alone  or  in  combination.  Also,  it  was  decided  for  any  other  tasks  requiring  the  waveguide  to  be 
disconnected  that  the  team  would  simulate  the  portions  of  the  task  that  would  create  the  need  for  a 
pressurization  test. 
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Subjects  1  and  2  did  this  combined  problem.  Except  for  the  difficulties  with  the 
pressurization  tester  and  the  problem  mentioned  above  of  losing  information  on  inspection  of  a 
cable  when  switching  to  the  more  detailed  track,  they  performed  smoothly  and  found  both  faults. 
They  were  surprised  to  discover  a  fault  still  remained  after  they  fixed  the  first  one,  but  they  pressed 
on  with  the  PMA  and  found  the  second  one. 

During  one  of  the  BITs  for  this  task,  the  subject  who  did  the  switch-setting  in  the  cockpit 
took  the  PMA  with  him  and  held  it  on  his  lap  to  see  if  he  could  accomplish  the  entire  test  by 
himself.  It  turned  out  to  be  possible,  but  uncomfortable.  The  PMA  procedure  was  easy  to  read 
and  the  illustrations  of  switch  locations  were  judged  to  be  adequate,  but  the  battery  pack  was  too 
bulky  to  be  handled  easily  on  one's  lap  in  the  cockpit.  The  subject  had  to  move  the  battery  pack 
back  and  forth  in  order  to  reach  necessary  cockpit  switches,  and  it  was  too  bulky  to  allow  one 
person  to  comfortably  carry  it  up  the  ladder  and  enter  the  cockpit  safely.  Another  person  had  to 
hand  the  PMA  to  the  subject  once  he  was  safely  seated  in  the  cockpit.  It  should  be  noted  that  one 
of  the  ultimate  goals  of  IMIS  is  to  obviate  the  need  for  the  maintenance  person  to  enter  the  cockpit 
at  all  in  order  to  run  BIT;  so,  this  apparent  shortcoming  of  the  PMA  is  moot. 

Problems  595  and  340.  This  combination  of  problems  was  handled  in  a  relatively 
straightforward  manner  by  all  subject  pairs.  The  fact  that  it  contained  multiple  faults  was  never 
initially  known  to  subjects  when  they  began.  Once  they  repaired  the  first  fault  and  ran  the  BIT,  a 
new  MFL  appeared;  and  they  simply  continued  to  troubleshoot  until  they  cleared  the  second  fault. 

Subjects  3  and  4  found  the  dummy  cable  (the  593  fault)  essentially  "by  the  book."  During 
a  continuity  check  while  working  on  the  340  fault,  they  misread  a  pin  number  on  a  power-panel 
connector  and  reported  a  bad  result  (it  was  really  good  on  the  correct  pin).  The  observer  stopped 
them  and  reset  the  PMA  to  the  continuity  check  again,  which  they  reported  correctly  this  time. 
Several  subjects  had  trouble  with  this  particular  connector.  It  is  large  and  has  a  confusing  pin¬ 
numbering  pattern  that  makes  it  easy  for  a  technician  to  err  in  selecting  the  proper  pin  to  check. 

These  two  subjects  recognized  the  bad  relay  from  the  day  before  (the  blue  plastic  case),  and 
they  decided  to  replace  it  instead  of  the  transmitter,  which  was  the  computer’s  first 
recommendation.  This  cleared  the  fault  and  they  finished  the  problem  without  further  incident. 

Subjects  5  and  6  found  both  problems  essentially  by  the  book,  except  they  chose  to  replace 
the  relay  instead  of  the  transmitter.  They  had  not  seen  the  blue  relay  before,  but  they  admitted  they 
guessed  the  demonstration  team  was  more  likely  to  have  bugged  a  relay  than  a  transmitter.  They 
did  say,  though,  that  on  the  flight  line  in  a  similar  situation,  they  would  have  "slaved,"  or 
cannibalized,  a  transmitter  (swapped  the  suspected  transmitter  with  a  known  good  one  from 
another  aircraft  on  the  line),  which  was  the  number  one  recommendation.  Their  only  procedural 
error  was  resetting  a  circuit  breaker  before  the  procedure  told  them  to  (as  discussed  earlier). 

For  the  most  part,  Subjects  7  and  8  went  through  these  problems  smoothly.  One  of  the 
subjects,  however,  was  completely  unskilled  in  the  use  of  a  multimeter  for  continuity  checks.  He 
confused  the  conditions  of  "open"  and  "short,”  and  would  have  responded  incorrectly  to  the 
question  about  continuity  ("Is  continuity  present ...  ?")  if  the  observer  had  not  interrupted.  He 
also  left  a  connector  disconnected  after  the  continuity  check,  but  the  other  subject  caught  it  before 
they  ran  the  BIT. 

Subjects  y  and  10  both  were  relatively  inexperienced  with  the  radar  system;  neither  was 
familiar  with  system  geography,  particularly  cable  and  connector  locations.  They  had  considerable 
difficulty  locating  specified  connectors,  even  when  they  switched  to  the  more  detailed  track.  They 
later  complained  that  the  illustrations  and  diagrams  should  have  had  more  detail  on  locating  pins  on 
connectors.  When  they  began  to  work  on  problem  340,  they  had  a  hard  time  finding  the  correct 
pin  at  the  power  panel  (the  same  connector  which  troubled  Subjects  3  and  4). 
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Again,  one  of  the  subjects  was  misled  by  the  question  asking  if  the  PMA  was  connected  to 
the  aircraft;  he  saw  that  it  was  not,  and  simply  chose  the  "no"  answer  (the  author  had  evidently 
intended  that  the  user  hook  up  the  cable,  then  answer  "yes").  Being  unable  to  back  up  in  the 
procedure,  the  observers  had  to  reset  the  procedure  before  running  the  BIT. 6 

When  the  subjects  reached  the  point  where  the  computer  recommended  replacing  the 
transmitter,  they  balked  (having  come  to  expect  simpler  problem  solutions  from  the  demonstration 
team),  explored  options,  and  elected  to  replace  the  relay  instead.  Replacement  of  the  relay 
followed,  but  the  subjects,  who  had  never  removed  a  relay  before,  believed  they  did  not  have  the 
correct-sized  socket  to  remove  the  attaching  nuts.  They  searched  for  several  minutes  before 
discovering  they  did,  in  fact,  have  the  propei  socket. 

Subjects  1 1  and  12  did  both  problems  entirely  by  the  book.  One  of  the  subjects  was  much 
more  experienced  than  the  other,  who  was  both  inexperienced  and  a  poor  reader.  The  more 
experienced  individual  allowed  the  other  to  use  the  PMA  and  to  make  nearly  all  decisions.  The 
PMA  user,  who  was  uneasy  in  the  troubleshooting  situation,  elected  to  go  with  all  of  the 
computer's  recommendations.  Apparently,  he  felt  unqualified  to  second-guess  it,  and  received  no 
advice  from  his  more  experienced  partner. 

The  less  experienced  subject  appeared  to  be  mistakenly  selecting  the  "INFO"  key  instead  of 
the  "NEXT"  key  when  he  intended  to  advance  to  the  next  step.  When  asked  later  about  that 
frequent  apparent  error,  he  reported  that  he  had  really  been  searching  for  a  way  to  "preview"  or 
browse  ahead  and  review  a  procedure  before  actually  making  the  commitment  to  perform  it.  He 
was  mildly  relieved  to  learn  that  the  reason  he  had  not  found  that  information  was  that  no  such 
feature  currently  exists. 

As  described  earlier  for  another  subject,  when  this  subject  switched  to  the  more  detailed 
jack  for  connector  location  information  during  the  continuity  check,  he  lost  the  spot  in  the 
procedure  where  he  should  have  been  directed  to  inspect  the  cable,  and  it  appeared  the  PMA  was 
directing  him  to  repair  the  cable  without  even  checking  it.  Like  several  other  subjects,  he  also 
tended  to  "jump  the  gun"  at  the  point  of  checking  the  circuit  breaker,  wanting  to  do  most  of  the 
procedural  steps  before  being  directed  to  do  them  by  the  PMA. 


Task  Debriefing 

Because  the  observer’s  notes  tended  to  cover  the  nature  of  most  of  the  problems 
encountered  by  the  subjects,  each  debriefing  session  focused  on  the  subject's  general  likes  and 
dislikes  of  the  preceding  task’s  performance.  The  responses  are  contained  in  Appendix  B. 


Questionnaire  Results 


The  questionnaires  were  administered  to  subjects  after  they  had  finished  all  of  the  problems 
assigned  to  them.  A  complete  sample  questionnaire  is  presented  in  Appendix  B.  The  first  21 
items  were  topics  on  which  the  subjects  were  asked  to  rate  the  PMA.  either  by  itself  or  in 
comparison  with  paper  IDs.  Their  individual  and  mean  ratings  for  these  items  are  presented  in 
Table  7. 


^This  problem  has  since  been  corrected.  Originally  it  was  designed  for  laboratory 
demonstration  purposes  to  have  the  "no"  answer  produce  a  "pass"  result  for  the  BIT. 
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The  remainder  of  the  questionnaire  consisted  of  open-ended  questions  with  spaces  where 
the  subjects  could  write  their  responses.  Appendix  B  contains  the  complete,  verbatim  response 
of  each  subject  who  responded  for  each  question. 


Table  7.  Questionnaire  Responses 


Ouestion 

C 

biect  Number 

1 

2 

4 

-6- 

_2_ 

JL 

_2_ 

JiL 

_Ji_ 

12 

Mean 

1  Location  of  keys 

4 

5 

3 

3 

4 

5 

5 

4 

3 

5 

3 

3 

3.92 

2  Spacing  of  keys 

4 

5 

3 

4 

4 

5 

5 

4 

3 

4 

3 

3 

3.92 

3  Ease  of  operating  key 

4 

5 

4 

4 

4 

5 

5 

4 

3 

3 

3 

3 

3.92 

4  Key  tactile  feedback 

3 

5 

4 

4 

4 

4 

4 

4 

3 

4 

3 

3 

3.75 

5  Response  time 

3 

5 

5 

4 

3 

4 

4 

4 

4 

- 

4 

2 

3.82 

6  Screen  size 

3 

5 

5 

4 

3 

5 

5 

2 

3 

3 

4 

4 

3.83 

7  White  space/clutter 

4 

5 

4 

3 

4 

5 

5 

2 

4 

4 

4 

3 

3.92 

8  Screen  brightness 

4 

5 

5 

3 

4 

5 

5 

4 

4 

5 

4 

3 

4.25 

9  Screen  glare 

4 

5 

5 

4 

4 

4 

5 

4 

3 

5 

3 

3 

4.08 

10  Large  character  legibility 

4 

5 

4 

3 

4 

5 

5 

4 

3 

5 

4 

3 

4.08 

1 1  Small  character  legibility 

4 

5 

4 

3 

4 

5 

5 

4 

3 

5 

4 

3 

4.08 

12  Graphics  legibility 

3 

5 

5 

2 

2 

4 

4 

2 

2 

1 

4 

3 

3.08 

13  Graphics  detail 

3 

4 

5 

3 

2 

3 

4 

2 

2 

1 

4 

3 

3.00 

14  Organization  of  information 

5 

5 

4 

2 

3 

5 

5 

4 

3 

3 

3 

4 

3.83 

15  Options  menus/function  keys 

4 

4 

4 

3 

3 

4 

5 

4 

4 

4 

2 

3 

3.67 

16  Use  of  menus/function  keys 

4 

5 

5 

3 

4 

5 

5 

4 

4 

4 

2 

3 

4.00 

17  Adequacy  of  graphics 

3 

5 

5 

3 

3 

4 

4 

2 

2 

1 

4 

3 

3.25 

18  Adequacy  of  information 

4 

5 

2 

3 

4 

4 

5 

4 

3 

3 

4 

3 

3.67 

19  Time/effort  to  do  task 

5 

4 

5 

3 

4 

5 

5 

4 

3 

3 

3 

5 

4.08 

20  Tirne/effort  for  more  detail 

5 

5 

4 

3 

4 

5 

5 

4 

3 

3 

4 

5 

4.17 

21  Is  PCMAS  an  improvement? 

4 

4 

5 

- 

3 

4 

4 

4 

2 

4 

4 

5 

3.91 

_M2 

Rating  Scale:  1  Unsatisfactory 

2  Marginal 

3  Satisfactory 

4  Highly  Satisfactory 

5  Outstanding 

_ -  Can't  Evaluate  (or  no  response) 


Final  Debriefing 

During  the  Final  group  meeting  (debriefing),  the  group  considered  a  variety  of  topics. 
Topics  were  introduced  and  discussed  in  no  particular  order  for  a  period  of  approximately  1 
hour.  The  following  issues  were  raised  and  discussed. 

1.  The  BACKUP  function  does  not  work  well. 

2.  It  is  not  possible  to  browse  through  a  procedure  without  having  the  computer  think  you 
have  actually  performed  the  procedure. 

3.  Some  graphics  are  too  small.  "It's  hard  to  see  what  plugs  are  located  where." 
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4.  It  is  too  easy  to  overlook  the  "More  Information  Available"  message  (which  indicates 
that  a  piece  of  text  is  continued  but  lies  off-screen,  below  or  to  the  right  or  left).  It  was 
suggested  that  such  continued  material  just  be  put  on  the  next  screen, to  be  accessed  with  the 
NEXT  key  instead  of  continuing  to  risk  that  it  will  be  overlooked. 

5.  Detail  was  weak  in  some  of  the  graphics;  some  "looked  like  etch-a-sketch  drawings." 

6.  Of  the  extra  information  keys,  some  people  liked  the  OPTIONS  key  best.  They  liked 
being  able  to  see  their  most  logical  options,  instead  of  going  through  page  after  page  of  the  fault 
isolation  manual  or  such  things  as  their  (informal)  "flight  control  trivia"  book  of  historical  best 
options,  which  have  been  obtained  through  conversations  with  various  bases. 

7.  Some  technicians  liked  the  "Failure  Probability"  information  provided  by  the  IMIS-DM. 
They  used  it  and  think  it  helped  with  their  decision-making. 

8.  During  the  study,  some  subjects  based  troubleshooting  decisions  on  what  kinds  of 
"bugs"  they  thought  the  study  team  might  have  installed,  instead  of  what  the  logical  solution 
should  have  been. 

9.  Several  subjects  liked  the  block  diagram  showing  plausible,  maybe,  and  exonerated 
components.  "I  liked  the  way  the  block  diagram  showed  what  was  going  on."  "The  block 
diagram  feature  would  be  valuable  for  shift  changes  [to  communicate  to  the  next  shift  what  you 
had  done  so  far,  and  what  you  had  found  out]." 

10.  Breaking  the  high-level  block  diagram  into  three  subdiagrams  for  the  radar  "...was  the 
best  way  to  partition  the  larger  block  diagrams." 

11.  The  PMA  was  easier  to  carry  than  a  bunch  of  TOs. 

12.  The  data  base  should  have  included  power-on  and  power-off  procedures  to  make  it 
consistent  with  die  way  other  input  condition  items  were  treated. 

13.  The  IMIS  system  must  develop  some  visual  indication  to  the  user  when  pieces  of 
procedures  have  been  revised  or  updated.  The  scheme  could  use  vertical  bars  in  the  margins  like 
the  present  paper  TOs. 

14.  Some  liked  the  (simulated)  availability  of  history  information  from  CAMS.  They 
thought  it  would  be  very  helpful. 

15.  Some  subjects  are  presently  leery  of  CAMS.  The  system  goes  down  a  lot,  and  loses 
some  information  that  people  have  entered  into  it. 

16.  Some  technicians  want  more  theory,  to  back  up  the  computer's  recommendations. 
They  want  to  know  "why"  something  is  recommended,  rather  than  just  being  given  a  list  of 
functions  that  particular  components  perform.  Some  also  mentioned  a  desire  for  theory  on  what 
functions  are  being  tested  during  continuity  checks. 
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V.  DISCUSSION 


The  IMIS-DD  is  simply  what  it  was  intended  to  be:  a  demonstration  of  the  diagnostic 
capabilities  of  the  PMA  and  the  IMIS-DM.  It  was  the  first  of  two  efforts  to  validate  and  test 
diagnostic  concepts  for  implementation  in  the  IMIS  program.  The  demonstration  was  an  initial 
proof-of-concept  effort  to  test  and  refine  the  concepts  and  tools  necessary  to  provide  the  diagnostic 
capability  for  the  IMIS.  As  such,  it  was  not  intended  to  be  an  exhaustive  evaluation  of  the  MIS 
diagnostic  technology;  rather,  it  was  intended  as  a  step  in  the  development  of  this  technology.  The 
basic  objectives  were  (a)  to  verify  the  validity  of  the  IMIS-DM  by  testing  it  under  "real-world" 
conditions,  (b)  to  verify  the  feasibility  of  using  the  IMIS-DM  and  a  portable  computer  to  activate 
the  BIT  and  directly  access  system  status  data  via  the  aircraft's  MIL-STD-1553  data  bus,  (c)  to 
obtain  data  on  the  degree  to  which  the  technicians  were  able  to  solve  troubleshooting  problems 
using  the  system,  and  (d)  to  identify  ways  to  improve  the  system. 

Although  the  limited  number  of  subjects  and  time  available  for  the  demonstration  made  it 
impossible  to  conduct  a  carefully  controlled,  experimental  study,  the  basic  objectives  of  the  effort 
were  achieved.  The  demonstration  showed  that  the  EMIS-DM  does  provide  an  effective  diagnostic 
capability,  the  PMA  and  IMIS-DD  can  activate  the  aircraft's  BIT  and  download  data  for  use  in  the 
diagnostic  process,  and  the  technicians  can  effectively  use  the  PMA  and  IMIS-DM  to  solve 
troubleshooting  problems.  Many  valuable  lessons  were  learned-most  in  the  user  interface  area. 

The  IMIS-  DM  effectively  resolved  all  of  the  test  problems.  Although  no  data  were 
available  to  compare  the  diagnostics  strategy  provided  by  the  IMIS-DM  with  the  strategy  provided 
to  the  technicians  for  troubleshooting  using  the  paper  TOs,  many  technicians  indicated  that  the 
strategy  proposed  by  the  system  was  the  same  or,  in  some  cases,  better  than  the  strategy  they 
would  have  implemented  if  they  had  been  working  on  their  own. 

The  major  portion  of  the  information  used  for  the  diagnostic  data  base  was  taken  from  the 
Fault  Isolation  (FI)  and  Job  Guide  Manuals.  However,  some  diagnostic  information  used  by  the 
IMIS-DM  was  developed  by,  or  through  discussions  with,  maintenance  expens.  This  extra 
information  went  beyond  the  help  available  in  the  FIs;  so,  theoretically,  the  very  least  the  PMA  can 
do  as  a  performance  aid  for  troubleshooting  should  be  equivalent  to  the  best  that  the  relevant  FIs 
could  do.  A  clear  implication  is  that  an  individual  who  is  completely  dependent  on  his  or  her  job 
aid  would  be  able  to  solve  more  problems  using  a  PMA  than  FIs. 

The  capability  to  connect  the  PMA  to  the  MIL-STD-1553  data  bus,  use  the  PMA  to  initiate 
the  aircraft's  BIT  capability,  and  utilize  the  results  to  guide  the  diagnostic  process  was 
demonstrated.  The  technicians  connected  the  PMA  to  the  aircraft’s  MIL-STD-1553  data  bus  and 
downloaded  fault  information,  then  used  the  PMA  as  the  single  source  of  diagnostic  and 
procedural  information  to  support  troubleshooting.  This  demonstrated  the  feasibility  of  the  basic 
concept;  however,  the  full  potential  of  the  concept  was  not  demonstrated  in  that  the  F- 16  has 
relatively  limited  capabilities  for  accessing  data  through  the  MIL-STD-1553  data  bus.  The 
available  data  are  limited  to  results  from  the  BIT  in  addition  to  the  in-flight  failures  recorded  on  the 
aircraft's  DTU.  Newer  aircraft,  such  as  the  F/A-18,  have  improved  data  access  through  the  data 
bus.  This  will  allow  a  PMA  device  to  access  data  such  as  the  contents  of  selected  memory 
locations  on  aircraft  systems  for  use  in  the  diagnostic  process. 

Although  some  problems  were  encountered,  the  technicians  found  the  system  easy  to  use. 
They  were  able  to  perform  the  assigned  tasks  after  only  very  limited  training  (about  1  hour).  Most 
of  the  problems  the  technicians  encountered  using  the  system  resulted  from  inexperience  with  the 
system;  these  difficulties  most  likely  would  be  overcome  with  experience.  However,  several 
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weaknesses  were  identified  which  require  correction  for  the  system  to  be  fully  satisfactory  from 
the  user’s  point  of  view. 

The  most  serious  user  problem  was  the  difficulty  the  technicians  occasionally  had  in 
deciding  what  kind  of  information  they  wanted,  and  how  to  get  it.  Another  problem  arose  because 
current  software  does  not  contain  a  provision  for  the  user  to  "look  ahead"  and  explore  procedures 
he  or  she  is  unsure  of  and  might  want  to  perform.  Nor  does  the  software  have  a  pure  "backup" 
function  to  perform  a  backward  tracing  of  all  screens  previously  viewed  in  the  current  session. 

Both  of  these  capabilities  would  have  been  beneficial  as  the  subjects  had  a  low  level  of  experience 
with  the  PMA.  Sometimes  an  inexperienced  user  feels  lost  or  uneasy,  but  is  not  sure  whether  he 
or  she  is  really  lost.  In  such  cases,  being  able  to  look  forward  in  the  data  base  or  to  step  backward 
and  review  the  session's  protocol  up  to  the  current  point  would  allow  the  hesitant  user  to  determine 
exactly  what  has  been  done  and  where  the  session  is  going. 

A  related  problem  is  the  present  treatment  of  the  two  levels  of  detail  (two-track)  feature.  As 
implemented,  the  two  tracks  are  parallel  rather  than  overlaid,  as  with  "hypertext."  Within  a  task,  if 
a  person  goes  through  several  steps  in  one  track  and  then  decides  to  shift  to  the  other  track,  he  or 
she  is  sent  back  to  the  beginning  of  the  task  steps  in  the  previous  track.  This  resetting  to  the 
beginning  was  viewed  by  the  demonstration  subjects  more  as  an  aberration  than  a  desirable  feature. 
Technicians  who  attempted  to  shift  levels  were  generally  a  bit  uneasy  when  they  found  themselves 
at  the  beginning  of  the  sequence  of  steps.  Suddenly  finding  themselves  at  a  different  point,  with  a 
different  level  of  descriptive  detail,  was  somewhat  confusing.  At  best,  such  a  mechanism  wastes 
time  while  the  user  reads  through  the  procedure  to  get  back  to  the  step  being  performed  when  the 
decision  to  shift  was  made.  At  worst,  it  can  be  so  disorienting  the  user  believes  he  or  she  has 
made  a  mistake  and  has  somehow  jumped  to  another  (perhaps  inappropriate)  task;  the  user  then  has 
to  stop  completely  in  order  to  figure  out  where  he  or  she  is  in  the  procedure. 

As  with  most  features  of  the  current  implementation,  the  track-shifting  problem  would 
undoubtedly  become  less  of  a  problem  as  users  accumulated  sufficient  experience  with  the  device. 
A  track-changing  feature  permitting  a  user  to  shift  back  and  forth  between  levels  without  losing  his 
or  her  place  or  restarting  the  procedure  would  clearly  be  an  improvement;  its  use  would  be  more 
intuitive,  especially  for  the  inexperienced  technician. 

Problems  were  encountered  with  some  of  the  graphics:  (a)  some  were  too  small,  (b)  others 
did  not  have  enough  detail,  (c)  some  were  inadequate  or  had  missing  callouts,  and  (d)  some 
necessary  graphics  were  not  available.  Most  of  the  graphics  were  legible,  but  many  were  not  sized 
to  take  advantage  of  available  screen  space  (a  small  drawing  might  appear  in  the  lower  right  comer 
of  an  otherwise  mostly  blank  screen),  and  many  suffered  from  missing  or  misaligned  callouts  and 
leader  lines.  These  problems  presented  few  difficulties  to  the  experienced  subjects  because  these 
subjects  were  generally  familiar  with  the  objects  portrayed  and  did  not  really  need  illustrations  to 
find  the  objects.  Several  inexperienced  individuals  were  not  helped  at  all  by  some  of  the  graphics. 
It  was  particularly  difficult  for  people  who  were  inexperienced  in  troubleshooting  wiring  problems 
or  uncertain  of  the  system  geography  to  decipher  some  illustrations  showing  connector  locations. 
These  same  people  also  expressed  a  desire  for  additional  drawings  to  help  them  locate  specified 
pins  on  large,  multi-pin  connectors  with  arcane  numbering  patterns.  Some  of  the  subjects 
preferring  somewhat  more  detailed  graphics  complained  about  the  "Etch-a-Sketch"  quality  of  many 
of  the  existing  graphics.  Although  graphics  taken  from  technical  orders  were  included  in  the  data 
base  for  most  procedures,  the  tight  predemonstration  schedule  had  not  allowed  enough  time  to 
develop  adequate  graphics  to  support  some  procedures.  One  example  is  the  lack  of  a  graphic  to 
show  the  location  of  the  throttle-grip  connector.  The  Job  Guides  and  FIs  provided  no  graphic 
support  for  that  procedure  either.  Thus,  the  PMA  was  still  no  worse  than  the  combination  of 
existing  Job  Guides  and  FIs  in  the  guidance  it  provided.  Although  most  of  the  technicians  were 
able  to  "work  around"  inadequate  graphics,  the  study  clearly  points  to  a  need  for  an  increased 
emphasis  on  developing  effective  graphics  for  future  tests  and  demonstrations. 
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The  general  reactions  of  the  technicians  to  using  the  PMA  and  IMIS-DM  were  very 
positive.  They  were  favorably  impressed  with  the  capabilities  of  the  PMA,  and  most  indicated  they 
would  use  it  regularly  if  given  a  chance.  Some  were  even  more  enthusiastic,  expressing  the  wish 
for  some  form  of  the  PMA  to  be  fielded  much  sooner  than  presently  planned.  A  few  wanted  to 
take  the  device  with  them,  even  though  they  realized  its  data  base  covered  only  the  FCR  system. 

All  of  the  subjects  had  experience  with  CAMS.  They  respected  its  data  base,  but  strongly 
disliked  its  user  interface.  They  readily  appreciated  the  desirability  of  using  a  PMA  as  their  single 
point  of  interface  with  CAMS  and  the  base  supply  system.  Without  exception,  they  were  very 
impressed  when  the  PMA  presented  automatically  filled-in  CAMS  data  on  the  screen  at  the  end  of 
each  task. 

The  PMA  computer  proved  to  be  an  effective  research  tool  for  testing  the  IMIS-DM  and 
evaluating  the  use  of  a  portable  computer  to  present  technical  information  for  on-equipment 
maintenance.  It  provided  all  required  capabilities  in  an  efficient  manner,  and  the  technicians 
seemed  to  like  using  it.  The  major  complaint  was  that  it  is  too  large  and  too  heavy  for  convenient 
use  on  the  flight  line.  Some  technicians  also  expressed  a  concern  regarding  the  ability  of  a 
computer  to  withstand  the  rough  treatment  it  would  receive  on  the  flight  line.  These  objections 
were  withdrawn  when  it  was  explained  that  a  much  smaller  version  is  under  development  and 
fielded  systems  will  be  small,  and  ruggedized  to  withstand  the  rigors  of  the  flight  line. 


Conclusions 

Much  valuable  information  was  gained  from  the  demonstration.  The  objectives  were 
successfully  met,  and  AFHRL  was  able  to  collect  constructive  feedback  to  apply  to  future 
demonstrations.  It  was  shown  that  a  portable  computer  could  be  used  for  on-equipment 
maintenance  to  assist  in  troubleshooting  and  repair  procedures.  The  computer  was  able  to  integrate 
diagnostics  with  technical  data,  as  well  as  initiate  the  BIT  to  gain  information  for  the  diagnostics. 
Some  problems  exist,  as  discussed;  but  overall,  the  reaction  to  an  IMIS  system  was  extremely 
positive. 


Follow-On  Efforts 

The  lessons  learned  in  the  IMIS-DD  are  being  applied  in  follow-on  efforts  to  refine  and  test 
the  IMIS-DM  technology. 


IMIS-DM  Redesign/Enhancement 

The  IMIS-DM  and  its  predecessor,  MDAS,  have  evolved  over  the  years.  The  software  has 
been  modified  and  new  features  added  as  requirements  were  identified  and  new  procedures 
developed.  As  a  result,  the  IMIS-DM  code  is  not  as  efficient  as  it  should  be.  Therefore,  the  IMIS- 
DM  and  the  supporting  software  are  being  completely  redesigned  and  recoded  to  increase  their 
efficiency,  add  new  capabilities,  and  provide  increased  flexibility.  The  software  is  being  written  in 
an  object-oriented  programming  language  to  provide  for  easier  growth. 


Small  PMA 

Work  is  in  progress  to  develop  a  PMA  which  is  much  smaller  than  the  PCMAS  II  unit  used  for  the 
IMIS-DD  project.  The  new  PMA  will  be  approximately  half  the  size  and  weight  of  the  PCMAS  II, 
will  provide  increased  internal  memory,  and  use  a  larger  capacity  memory  cartridge. 
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Content  Data  Mode! 


Evaluations  of  the  APS  indicated  that  it  provided  an  effective  tool  for  demonstrating  the  use 
of  a  neutral  data  base  to  create  and  display  automated  technical  data.  However,  a  number  of 
limitations  and  weaknesses  were  identified  which  required  resolution.  The  Content  Data  Model 
(CDM)  effort  was  established  to  address  these  problems. 

The  CDM  effort  involved  a  comprehensive  analysis  of  the  contents  and  requirements  for  all 
types  of  technical  data  required  to  maintain  Air  Force  systems.  The  required  data  elements  were 
identified,  as  well  as  the  attributes  required  to  describe  them;  and  the  interrelationships  between 
them  were  specified.  The  CDM  represents  data  in  a  neutral  format.  The  individual  elements  within 
the  CDM  are  uniquely  identified  and  can  be  retrieved  and  manipulated  individually.  Shared 
elements  within  the  data  base  are  represented  only  once,  eliminating  redundancy. 

The  CDM  is  being  developed  in  an  iterative  process.  Initial  specifications  have  been 
developed  and  tested.  These  specifications  are  being  updated  to  incorporate  the  results  of  the  tests 
and  to  expand  the  model  to  ensure  that  it  can  efi^ctively  represent  the  requirements  of  technical  data 
used  by  other  DOD  agencies.  Progress  on  the  development  of  the  CDM  is  described  in  Earl  et  al., 
1990. 

Authoring  and  Presentation  System  Revision 

The  authoring  and  presentation  system  is  being  revised  to  overcome  problems  identified  in 
this  and  previous  efforts.  The  system  is  being  designed  to  make  it  easier  for  authors  to  create  data 
and  to  make  the  data  compatible  with  neutral  data  stored  in  the  CDM  format  which  is  being 
developed  for  use  with  the  IMIS.  This  software  is  also  being  developed  in  an  object-oriented 
language. 

Improved  User  Interface 

Work  is  in  progress  to  develop  an  improved  user  intetface  for  the  IMIS.  Work  is  focusing 
upon  developing  an  interface  for  the  smaller  PMA  and  techniques  to  help  the  technician  easily 
locate  and  use  the  information  provided  by  the  PMA. 

F/A-18  Diagnostic  Demonstration 

Preparations  are  being  made  to  conduct  a  demonstration  and  evaluation  of  the  IMIS-DM 
using  the  F/A-18  aircraft.  The  F/A-18  Diagnostics  Demonstration  will  provide  a  much  more 
extensive  test  of  the  IMIS  diagnostic  technology.  It  will  include  a  controlled  evaluation  where 
performance  of  technicians  using  the  PMA/IMIS-DM  to  isolate  faults  in  an  F/A-18  subsystem 
will  be  compared  with  performance  of  technicians  using  paper  technical  manuals  to  troubleshoot 
the  subsystem.  In  addition,  it  will  include  an  unconstrained  field  test  where  technicians  will  use 
the  PMA  and  the  IMIS-DM  in  day-to-day  operations  to  troubleshoot  "real"  problems  in  the 
subsystem  as  they  are  encountered.  The  demonstration  will  use  the  redesigned  IMIS-DM,  the 
small  PMA,  and  the  improved  user  interface.  The  data  will  be  developed  using  the  redesigned 
authoring  and  presentation  systems.  The  F/A-18  demonstration  is  currently  scheduled  for  the  fall 
of  1990. 
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ACRONYMS 


A/C 

- 

Aircraft 

AFHRL 

- 

Air  Force  Human  Resources  Laboratory 

AFS 

- 

Air  Force  Specialty 

AFSC 

- 

Air  Force  Specialty  Code 

AGS 

- 

Aircraft  Generation  Squadron 

AIP 

- 

Aircraft  Interface  Panel 

AMU 

- 

Aircraft  Maintenance  Unit 

APS 

- 

Authoring  and  Presentation  System 

BIT 

- 

Built-in  Test 

CAMS 

- 

Core  Automated  Maintenance  System 

CDM 

- 

Content  Data  Model 

CMAS 

- 

Computer-based  Maintenance  Aid  System 

CMOS 

- 

Complementary  Metal  Oxide  Semiconductor 

DSP 

- 

Digital  Signal  Processor 

DTU 

- 

Data  Transfer  Unit 

FCC 

- 

Fire  Control  Computer 

FCR 

- 

Fire  Control  Radar 

FI 

- 

Fault  Isolation  Manual 

FOD 

- 

Foreign  Object  Damage 

FOM 

- 

Facilitate  Other  Maintenance 

GDE 

- 

General  Dynamics,  Electronics  Division 

GDFW 

- 

General  Dynamics  Fort  Worth 

IFF 

- 

Identify  Friend  or  Foe 

IMIS 

- 

Integrated  Maintenance  Information  System 

IMIS-DD 

- 

IMIS  Diagnostics  Demonstration 

IMIS-DM 

- 

IMIS  Diagnostic  Module 

JG 

- 

Job  Guide 

LCD 

- 

Liquid  Crystal  Display 

LPRF 

- 

Low  Power  Radio  Frequency  Unit 

LRU 

- 

Line  Replaceable  Unit 

MDAS 

- 

Maintenance  Diagnostic  Aiding  System 

MFL 

- 

Maintenance  Fault  List 

MIW 

- 

Maintenance  Information  Workstation 

MTBF 

- 

Mean  Time  Between  Failure 

OCU 

- 

Operational  Capability  Upgrade 

PCMAS 

- 

Portable  Computer-based  Maintenance  Aid  System 

PMA 

- 

Portable  Maintenance  Aid 

R&D 

- 

Research  and  Development 

R&R 

- 

Remove  and  Replace 

RDR 

- 

Radar 

SEI 

- 

Systems  Exploration,  Inc. 

SRL 

- 

Systems  Research  Laboratories 

SSC 

- 

Side  Stick  Controller 

TAC 

- 

Tactical  Air  Command 

TFW 

- 

Tactical  Fighter  Wing 

TO 

- 

Technical  Order 

WD 

- 

Wiring  Diagram 

XMTR 

- 

Transmitter 
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APPENDIX  A 


IMIS-DD  FAULT  INSERTION  LIST 


FAULT  01 

TITLE  -  Failed  56-MHz  Clock  input  to  Radar  Computer. 

SYMPTOM  EXPECTED  -  MFL  Radar  (RDR)  595,  "LPRF  Clock  Detect"  (BIT). 

MFL  RDR  018,  "LPRF  Clock  Detect"  (NAM). 

ACCESS  -  Door  1202. 

CAUTION  -  None. 

PROCEDURE  -  Power-Down  Radar,  Open  door,  Remove  cable,  Close  door,  Power-On. 

1.1  Shut  off  Radar  Power  by  switching  the  Radar  Panel  Mode  control  switch  to  "OFF."1 

1.2  Open  ACCESS  Door  1202. 

1 .3  Remove  56-MHz  cable  J4  from  Fire  Control  Radar  Computer. 

1 .4  Power-on  Radar  by  switching  the  Radar  Panel  Mode  Control  switch  to 
"AIR."  This  will  cause  the  Radar  to  perform  the  BIT  test  and  collect  the 
MFL  on  the  DTU  cartridge. 

1.5  Close  and  secure  door. 

1 .6  Perform  PCMAS  fault  isolation  using  the  MFL  collected  on  the  DTU 
cartridge. 

FAULT  02 

TITLE  -  Failed  56-MHz  Clock  input  to  DSP  in  BIT. 

SYMPTOM  EXPECTED  -  MFL  RDR  400  "DSP  Bus  External  WAT." 

ACCESS  -  Door  1202. 

CAUTION  -  None. 

PROCEDURE  -  Shut  Radar  off,  Open  door,  Remove  cable,  Close  door,  Power-On  Radar. 

2. 1  Shut  off  Radar  Power  by  switching  the  Radar  Panel  Mode  confrol  switch  to  "OFF." 

2.2  Open  Door  1202. 


1  Items  in  quotation  marks  are  identified  as  they  appear  on  the  aircraft. 
Fault  code  definitions  are  provided  in  the  94FI. 
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2.3  Remove  56-MHz  cable  J4  from  Digital  Signal  Processor. 

2.4  Close  and  secure  door. 

2.5  Power-on  Radar  by  switching  the  Radar  Panel  Mode  Control  switch  to 
"AIR."  This  will  cause  the  Radar  to  perform  the  BIT  test  and  collect  the 
MFL  on  the  DTU  cartridge.  Wait  for  the  BIT  test  to  complete  before 
proceeding. 

2.6  Perform  PCMAS  fault  isolation  using  the  MFL  collected  on  the  DTU 
cartridge. 

FAULT  03 

TITLE  -  Hardline  failed  between  Transmitter  (XMTR)  and  LPRF  in  BIT  mode. 

SYMPTOM  EXPECTED  -  MFL  RDR  319  "Xmtr  Calibration." 

ACCESS  -  Door  1202. 

CAUTION  -  None. 

PROCEDURE  -  Shuf  Radar  Off,  Open  door.  Remove  hardline,  Close  Door,  Turn  Radar  On. 

3. 1  Shut  off  Radar  Power  by  switching  the  Radar  Panel  Mode  control  switch  to  "OFF." 

3.2  Open  ACCESS  Door  1202. 

3.3  Remove  XMTR  to  LPRF  hardline  cable  2J7  using  9/16"  open-end  wrench. 

3.4  Close  and  secure  door. 

3.5  Power-on  Radar  by  switching  the  Radar  Panel  Mode  Control  switch  to 
"AIR."  Tnis  will  cause  the  Radar  to  perform  the  BIT  test  and  collect  the 
MFL  on  the  DTU  cartridge. 

3.6  Perform  PCMAS  fault  isolation  using  the  MFL  collected  on  the  DTU 
cartridge. 

FAULT  04 

TITLE  -  Potentiometer  Failure  in  Throttle  Grip  Found  during  BIT. 

SYMPTOM  EXPECTED  -  MFL  RDR  572  "A/D  Circuits"  (BIT). 

MFL  RDR  017  "A/D  Circuits"  (NAM). 

ACCESS  -  Cockpit. 

CAUTION  -  None. 

PROCEDURE  -  Shut  Radar  Off,  Remove  Cable. 

4. 1  Shut  off  Radar  Power  by  switching  the  Radar  Panel  Mode  control  switch  to  "OFF." 
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4.2  Disconnect  the  Throttle  Grip  cable  connector.  Note:  Thus  will  require  removal  of  the  Identify 
Friend  or  Foe  (IFF)  Control  Box  to  FOM. 

4.3  Power-on  Radar  by  switching  the  Radar  Panel  Mode  Control  switch  to 
"AIR."  This  will  cause  the  Radar  to  perform  the  BIT  and  collect  the 

MFL  on  the  DTU  cartridge. 

4.4  Perform  PCMAS  fault  isolation  using  the  MFL  collected  on  the  DTU 
cartridge. 

FAULT  05 

TITLE  -  No  control  of  antenna  elevation  from  forward  cockpit  (B  model). 

SYMPTOM  EXPECTED  -  Antenna  does  not  move  to  elevation  position  commanded  by  ANT 
ELEV  switch  on  forward  throttle  grip  but  is  OK  when  commanded  by  ANT  ELEV  switch  on  aft 
throttle  grip. 

ACCESS  -  Cockpit. 

CAUTION  -  Will  require  approximately  2  hours  to  insert  fault.  High 
probability  of  Foreign  Object  Damage  (FOD)  in  cockpit. 

PROCEDURE  -  Turn  A/C  off,  remove  T-Grip,  install  faulty  T-Grip,  turn  A/C  on,  perform  BIT 
test,  perform  Ops.  Check,  R&R  faulty  T-Grip,  perform  T-Grip  Ops.  Check. 

5. 1  Power-off  the  A/C  arid  remove  cooling  air.  Secure  A/C  by  performing 
Aircraft  Safe  for  Maintenance  (JG 10-30-01). 

5.2  Remove  the  T-Grip  assembly  and  install  a  faulty  T-Grip  with  an  open 
Ant.  Elev.  Switch. 

5.3  Power-up  A/C  and  apply  cooling  air. 

5.4  Power-on  Radar  by  switching  the  Radar  Panel  Mode  Control  switch  to 
"AIR."  At  completion  of  RDR  BIT,  no  additional  MFLs  should  have  occurred. 

5.5  Perform  Throttle  Grip  Operational  Checkout  per  94JG-60- 1 ,  paragraph 
3-14.  Failure  should  be  noted  directing  fault  isolation  at94-61-EN. 

5.6  Perform  PCMAS  fault  isolation  using  operator-observed  failure  EN. 

PCMAS  should  direct  Remove  and  Replace  (R&R)  of  the  Throttle-Grip  (T-Grip). 

FAULT  06 

TITLE  -  No  control  of  antenna  elevation  (B  model). 

SYMPTOM  EXPECTED  -  Antenna  does  not  move  to  elevation  position  commanded  by  ANT 
ELEV  switch  on  forward  throttle  grip  but  is  OK  when  commanded  by  ANT  ELEV  switch  on  aft 
ihi'Oitle  giip. 

ACCESS  -  Crew  compartment  matrix  assembly. 

CAUTION  -  None. 
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PROCEDURE  -  Turn  A/C  off,  remove  relay  9473K5,  install  faulty  relay,  turn  A/C  on,  perform 
BIT  test,  perform  Ops.  check,  R&R  faulty  relay,  perform 
T-Grip  Ops.  Check. 

6. 1  Power-off  the  A/C  and  remove  cooling  air.  Secure  A/C  by  performing 
Aircraft  Safe  for  Maintenance  (JG 10-30-01). 

6.2  Remove  relay  9473K5  and  install  a  faulty  relay  with  pins  cut  to  cause 

the  relay  to  be  open  between  B2  &  B3,  C2  &  C3,  D2  &  D3,  in  the  not-energized  position. 

6.3  Power-up  A/C  and  apply  cooling  air. 

6.4  Power-on  Radar  by  switching  the  Radar  Panel  Mode  Control  switch  to 
"AIR."  At  completion  of  RDR  BIT,  no  additional  MFLs  should  have  occurred. 

6.5  Perform  Throttle  Grip  Operational  Checkout  per  94JG-60- 1 ,  paragraph 
3-14.  A  failure  should  be  noted  directing  fault  isolation  to  94-6 1-EN. 

6.6  Perform  PCMAS  fault  isolation  using  operator-observed  failure  EN. 

PCMAS  should  direct  R&R  relay. 

FAULT  07 

TITLE  -  No  control  of  antenna  elevation  (B  model). 

SYMPTOM  EXPECTED  -  Antenna  does  not  move  to  elevation  position  commanded  by  ANT 
ELEV  switch  on  either  forward  or  aft  throttle  grip. 

ACCESS  -  Crew  compartment  matrix  assembly. 

CAUTION  -  None. 

PROCEDURE  -  Turn  A/C  off,  remove  relay  9473K5,  install  faulty  relay,  turn  A/C  on,  perform 
BIT  test,  perform  Ops.  Check,  R&R  faulty  relay,  perform 
T-Grip  Ops.  Check. 

7. 1  Power-off  the  A/C  and  remove  cooling  air.  Secure  A/C  by  performing 
Aircraft  Safe  for  Maintenance  (JG  10-30-01). 

7.2  Remove  relay  9473K5  and  install  a  faulty  relay  with  pins  B2,  C2,  and 
D2  cut. 

7.3  Power-up  A/C  and  apply  cooling  air. 

7.4  Power-on  Radar  by  switching  the  Radar  Panel  Mode  Control  switch  to 
"AIR."  At  completion  of  RDR  BIT,  no  additional  MFLs  should  have  occurred. 

7.5  Perform  Throuie  Grip  Operational  Checkout  per  94JG-60- 1 ,  paragraph 
3-14.  Failure  should  be  noted  directing  fault  isolation  at  94-6 1-EO. 

7.6  Perform  PCMAS  fault  isolation  using  operator-observed  failure  EN. 

PCMAS  should  direct  R&R  relay. 
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FALJLm 

TITLE  -  FCR  Control  Transfer  to  Aft  Failure  Side  Stick  Controller  (SSC)  Fault  (B  model). 

SYMPTOM  EXPECTED  -  On  transfer  to  aft  cockpit,  the  Target  Designator  Box 
still  follows  front  cockpit  RDR  CURSOR  control. 

ACCESS  -  Cockpit. 

CAUTION  -  None. 

PROCEDURE  -  Turn  A/C  off,  install  faulty  Side  Stick  Controller  (SSC)  in  forward  cockpit,  turn 
A/C  on,  perform  BIT  test,  perform  SSC  Ops.  Check,  R&R  faulty  SSC,  perform  SSC  Ops.  Check. 

8.1  Power-off  the  A/C  and  remove  cooling  air.  Secure  A/C  by  performing 
Aircraft  Safe  for  Maintenance  (JG 10-30-01). 

8.2  Remove  the  SSC  assembly  and  install  an  SSC  with  a  faulty  DESIG  RET 
SRCH  switch. 

8.3  Power-up  A/C  and  apply  cooling  air. 

8.4  Power-on  Radar  by  switching  the  Radar  Panel  Mode  Control  switch  to 
"AIR."  At  completion  of  RDR  BIT,  no  additional  MFLs  should  have  occurred. 

8.5  Perform  Side  Stick  Controller  Operational  Checkout  per  94JG- 1 0-02, 
paragraph  2-2.  Failure  should  be  noted  directing  fault  isolation  at 

94-6 1-DZ. 


8.6  Perform  PCMAS  fault  isolation  using  operator-observed  failure  DZ. 
PCMAS  should  direct  R&R  of  forward  SSC. 

FAULT  09 

TITLE  -  FCR  Control  Transfer  to  Aft  Failure  Relay  Failure  (B  model). 

SYMPTOM  EXPECTED  -  On  transfer  to  aft  cockpit,  the  Target  Designator  Box 
still  follows  front  cockpit  RDR  CURSOR  control. 

ACCESS  -  Crew  Compartment  Matrix  Assy  5. 

CAUTION  -  None. 


PROCEDURE  -  Turn  A/C  off,  install  faulty  relay,  turn  A/C  on,  perform  BIT  test,  perform  SSC 
Ops.  Check,  R&R  faulty  relay,  perform  SSC  Ops.  Check. 


9. 1  Power-off  the  A/C  and  remove  cooling  air.  Secure  A/C  by  performing 


Aircraft  Safe  for  Maintenance  (JGI0- 30-01). 


9.2  Remove  the  relay  9473K6  from  the  Crew  Compartment  Matrix  Assy  5  and  install  a  faulty 
relay.  Relay  fault  can  be  caused  by  cutting  pin  Y1  or  Y2 

on  the  relay. 

9.3  Power-up  A/C  and  apply  cooling  air. 
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9.4  Power-on  Radar  by  switching  the  Radar  Panel  Mode  Control  switch  to 
"AIR."  At  completion  of  RDR  BIT,  no  additional  MFLs  should  have  occurred. 

9.5  Perform  Side  Stick  Controller  Operational  Checkout  per  94JG-I0-02, 
paragraph  2-2.  Failure  should  be  noted  directing  fault  isolation  at 

94-61 -DZ. 


9.6  Perform  PCMAS  fault  isolation  using  operator-observed  failure  DZ. 

PCMAS  should  direct  R&R  of  relay. 

FAULT  10 

TITLE  -  FCR  Control  Transfer  to  Front  Failure  Relay  Failure  (B  model). 

SYMPTOM  EXPECTED  -  On  transfer  to  front  cockpit,  the  Target  Designator  Box  still  follows  aft 
cockpit  RDR  CURSOR  control. 

ACCESS  -  Crew  Compartment  Matrix  Assy  5. 

CAUTION  -  None. 

PROCEDURE  -  Turn  A/C  off,  install  faulty  relay,  turn  A/C  on,  perform  BIT  test,  perform  SSC 
Ops.  Check,  R&R  faulty  relay,  perform  SSC  Ops.  Check. 

10. 1  Power-off  the  A/C  and  remove  cooling  air.  Secure  A/C  by  performing 
Aircraft  Safe  for  Maintenance  (JG 10-30-01). 

10.2  Remove  the  relay  9473K6  from  the  Crew  Compartment  Matrix  Assy  5  and  install  a  faulty 
relay.  Relay  fault  can  be  caused  by  cutting  pin  XI  or  X2 

on  the  relay. 

10.3  Power-up  A/C  and  apply  cooling  air. 

10.4  Power-on  Radar  by  switching  the  Radar  Panel  Mode  Control  switch  to 
"AIR."  At  completion  of  RDR  BIT,  no  additional  MFLs  should  have  occurred. 

10.5  Perform  Side  Stick  Controller  Operational  Checkout  per  94JG- 10-02, 
paragraph  2-2.  Failure  should  be  noted  directing  fault  isolation  at 

94-61 -ED. 

10.6  Perform  PCMAS  fault  isolation  using  operator-observed  failure  ED. 

PCMAS  should  direct  R&R  of  relay. 

FAULT  1 1 

TITLE  -  Pressure  Leak  In  Waveguide. 

SYMPTOM  EXPECTED  -  None. 

ACCESS  -  Door  1202. 

CAUTION  -  None. 
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PROCEDURE  -  Power-down  A/C,  Open  door,  Loosen  Valve,  Close  door,  Power-on  A/C. 


11.1  Power-off  the  A/C  and  remove  cooling  air.  Secure  A/C  by  performing 
Aircraft  Safe  for  Maintenance  (JG 10-30-01). 

11.2  Open  ACCESS  Door  1202. 

11.3  Loosen  Schrader  Valve  on  LPRF  to  simulate  faulty  waveguide. 

1 1.4  Power-on  A/C  and  apply  cooling  air. 

1 1.5  Close  and  secure  door. 

1 1.6  Perform  PCMAS  fault  isolation  using  RDR  033  as  if  pilot-observed 
failure.  PCMAS  should  direct  isolation  per  94-61  AH  sequence  and  cause 
operator  to  R&R  waveguide. 

FAULT  12 

TITLE  -  Transmitter  protect  computer  count. 

SYMPTOM  EXPECTED  -  MFL  340. 

ACCESS  -  Door  3308. 

CAUTION  -  None. 

PROCEDURE  -  Power-down  A/C,  Open  door,  install  faulty  relay,  turn  A/C  on,  perform  BIT, 
R&R  faulty  relay,  perform  BIT  test. 

1 2. 1  Power-off  the  A/C  and  remove  cooling  air. 

12.2  Remove  relay  9473 K1  from  AC/DC  Power  Panel  3  (Door  3308)  and  install  faulty  relay. 
Relay  fault  can  be  caused  by  cutting  pin  X 1  or  X2  on  the  relay. 

1 2.3  Power-up  A/C  and  apply  cooling  air. 

12.4  Power-on  Radar  by  switching  the  Radar  Panel  Mode  Control  switch  to 
"AIR."  At  completion  of  RDR  BIT,  MFL  340  should  be  present. 

12.5  Perform  PCMAS  fault  isolation  to  locate  faulty  relay. 
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APPENDIX  B 


USER  EVALUATION  QUESTIONNAIRE 


The  prototype  portable  maintenance  aid  you  used  to  perform  the  F-l  6  test  is  an  example  of  how 
technical  data  may  be  delivered  in  the  future.  Since  you  and  other  technicians  will  be  the  users  of 
such  a  device,  your  feedback  is  essential  to  the  development  of  such  a  system. 

Evaluate  the  questionnaire  items  using  the  5-point  scale  appearing  to  the  right  of  the  items.  Rate 
each  item  by  placing  an  "X"  in  the  appropriate  column.  Respond  to  as  many  of  the  items  as 
possible  but  recognize  that  there  may  be  some  items  you  cannot  evaluate  based  on  your  limited 
experience  with  the  maintenance  aid.  In  those  cases,  place  an  "X"  in  the  column  headed  "Can’t 
Evaluate." 


A.  BACKGROUND  INFORMATION 
Please  fill  in  the  following  information: 

NAME: _ 

Age: _  Sex: _ AFS: _ 

Job  Title _ 

How  long  have  you  been  in  the  Air  Force? _ 

How  long  have  you  been  in  maintenance? _ 

How  much  experience  do  you  have  with  the  F- 16  Radar  system? 
Have  you  had  any  formal  training  on  the  F-l 6  Radar  system? _ 
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B:  PHYSICAL  FEATURES 
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C:  INFORMATION  PRESENTATION 
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D:  COMPARATIVE  ASSESSMENT  WITH  PAPER 
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19. 

Overall  time  and  effort  required  for  performing  task 

20. 

Time  and  effort  required  to  obtain  more  detail 

21. 

Extent  to  which  it  represents  an  improvement  in 

displaying  maintenance  procedures 
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can't  evaluate  cant  evaluate 


E:  OPINIONS 


22.  Are  two  levels  on  detail  useful? 


23.  Are  two  levels  of  detail  enough?  _  If  not,  how  many? 

24.  What  did  you  like  about  the  automated  system? _ 


25.  What  did  you  dislike  about  the  automated  system? 


26.  If  you  had  a  choice,  would  you  use  the  computer  or  paper  TOs? 
Why? _ 


27.  What  would  you  do  to  improve  the  automated  system? 


28.  Do  you  foresee  any  problems  in  using  a  computer  on  the  flight-line  for  maintenance?  If  so, 
what  would  be  required  to  overcome  these  problems? _ 
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TASK  DEBRIEFING 


Because  the  observer’s  notes  tended  to  cover  the  nature  of  most  of  the  problems  encountered  by 
the  subjects,  each  debriefing  session  focused  on  the  subject’s  general  likes  and  dislikes  of  the 
preceding  task's  performance. 

The  following  items  were  derived  from  debriefing  responses  by  the  subjects  in  the  "Bad  Things" 
category: 

1.  There  are  some  missing  steps  to  "power-down"  the  aircraft  following  BIT.  There  should  be 
a  linked  procedure  to  tell  the  technician  to  do  so. 

2.  The  PCMAS  device  was  too  bulky  to  use  comfortably  in  the  cockpit. 

3.  There  was  a  tendency  to  hit  "NEXT"  too  soon,  and  then  wish  you  could  back  up  and  reread 
one  last  bit  of  information  from  the  previous  screen.  There  are  too  many  places  where  it's 
impossible  to  just  back  up  one  screen.  More  familiarity  with  PCMAS  would  help  you  to  use  it 
right,  but  this  problem  still  needs  to  be  solved. 

4.  It  is  hard  to  understand  the  screen  that  comes  up  immediately  after  you  run  BIT,  especially  if 
it  passes.  If  it  does,  the  screen  should  say  "no  faults"  or  something  like  that,  instead  of  just  leaving 
the  line  blank. 

5.  Unless  PCMAS  is  very  flexible,  experienced  people  will  go  ahead  and  do  a  task,  then  go 
back  to  PCMAS  after  they're  finished,  and  step  through  a  procedure  just  to  get  the  information  that 
needs  to  go  into  CAMS. 

6.  PCMAS  has  the  ability  to  consider  wiring  problems  in  its  diagnostics,  unlike  most  Fault 
Isolation  manuals.  Since  a  lot  of  users  won't  have  much  experience  with  wiring  problems, 
PCMAS  should  present  more  detailed  information  and  bigger  graphics  on  finding  connectors,  and 
on  locating  pins  on  connectors. 

7.  When  you're  told  to  repair  a  cable  after  a  continuity  check,  you  should  still  be  able  to  see  the 
pin  numbers  that  correspond  to  the  bad  wires,  in  case  you  forget  what  they  were. 


The  following  items  were  selected  from  debriefing  responses  in  the  "Good  Things"  category: 

1.  PCMAS  found  a  wire  problem.  We  probably  would  have  swapped  a  box  first  if  we  hadn't 
had  PCMAS.  I  like  something  that  can  find  wire  problems.  They're  hard  to  troubleshoot  with 
TOs. 

2.  The  logic  that  PCMAS  uses  is  good.  Swapping  the  transmitter  was  logical  [in  this  task], 
even  though  the  relay  would  have  been  easy  to  swap.  The  transmitter  is  what  we  would  have  done 
on  our  own. 

3.  You  get  faults  quicker  when  PCMAS  runs  BIT  instead  of  the  aircraft. 

4.  When  we  use  the  TOs,  we  don't  usually  check  that  breaker  first,  because  the  TOs  don't  tell 
you  to  do  it. 

5.  In  PCMAS,  all  the  TOs  are  together,  right  in  the  computer. 

6.  Like  the  availability  of  history  information.  We  use  it  a  lot.  This  is  a  lot  easier  than  CAMS. 
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7.  If  this  were  connected  to  CAMS,  when  you  were  done  with  a  job  you  wouldn't  have  to  close 
the  job  in  CAMS. 

8.  PCMAS  has  the  potential  to  track  serial-number-controlled  items. 

Effectivity  tracking  is  a  big  improvement.  The  following  items  were  derived  from  responses  to 
the  question,  "Do  you  have  any  other  comments  or  observations  about  the  use  of  PCMAS  during 
this  particular  task?": 

1.  The  demonstration  team  should  have  developed  a  better  introduction,  making  it  clear  that  in 
its  final  form,  IMIS  will  not  require  somebody  in  the  cockpit  to  run  BIT. 

2.  We  just  don't  use  Job  Guides  on  the  line  for  things  that  we  know  how  to  do,  like  replacing  a 
transmitter  or  LPRF. 

3.  PCMAS  needs  a  preview  function  that  lets  you  look  ahead  at  a  procedure  without  intending  to 
do  it.  You  ought  to  be  able  to  do  this,  to  prepare  for  doing  a  task,  before  you  start  it. 

4.  I'd  like  to  be  able  to  get  "MORE"  information  about  only  a  single  step  at  a  time  [instead  of 
getting  it  for  a  whole  task  at  a  time],  like  hypertext. 


EVALUATION  QUESTIONNAIRE  RESPONSES 


The  questionnaires  were  administered  to  subjects  after  they  had  finished  all  of  the  problems  that 
were  assigned  to  them.  The  first  21  items  were  topics  on  which  the  subjects  were  asked  to  rate 
PCMAS,  either  by  itself  or  in  comparison  with  paper  tech  orders  (See  Table  7,  Section  IV). 

The  remainder  of  the  questionnaire  consisted  of  open-ended  questions  with  spaces  in  which  the 
subjects  could  write  their  responses.  The  following  paragraphs  present  questions  22  through  28. 

The  complete  written  comments  of  each  subject  who  responded  to  the  question  are  transcribed  exactly 
as  written  by  the  technicians. 

(22)  Are  two  levels  of  detail  useful? 

1 .  Yes!  Helps  the  more  experienced  person  to  repair  the  aircraft  quicker  and  yet  offers  a  way 
for  the  less  experienced  to  access  detailed  instructions  they  might  need. 

2.  Yes,  if  you  don't  quite  understand  exactly  what  it  is  the  computer  wants  you  to  do,  it  will  go 
into  better  detail  for  you. 

3.  Can't  evaluate,  did  not  use  that  much. 

5.  The  only  level  used  during  this  procedure  was  the  top  level;  1  found  no  use  to  reduce  to  the 

other. 

6.  Yes.  When  certain  procedures  are  unclear,  a  more  detailed  picture  helps  in  finding  whai  is 
io  be  worked  on. 

7.  Yes,  because  experienced  personnel  may  opt  not  to  use  the  higher  detail  level,  saving 
manhours.  It  also  gives  the  less  experienced  personnel  more  independence. 
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9.  Yes.  For  the  experienced  person,  few  details;  and  for  the  inexperienced,  detailed  drawings 
and  directions. 

10.  There  should  be  an  expert  level  with  a  listing  of  the  procedures  and  the  ability  to  expound 
on  individual  steps,  thus  enabling  the  worker  to  have  an  overview  of  the  procedures,  especially  if  he 
or  she  is  extremely  qualified. 

11.  Yes!  I  think  that  you  should  have  the  option. 

12.  Yes.  Allows  for  diversity  of  experience  and  skill  levels. 

(23)  Are  two  levels  of  detail  enough?  If  not,  How  many? 

1.  Ten  subjects  answered  YES;  one  did  not  respond. 

2.  Subject  number  10  answered  "Three:  No  details;  Some  details;  and  All  (very 
comprehensive)." 

(24)  What  did  you  like  about  the  automated  system? 

1.  Speed  for  troubleshooting  wiring  problems,  history. 

2.  Seems  it  would  speed  up  troubleshooting  time  on  a  big  job. 

3.  I  preferred  seeing  the  illustration  using  graphics  than  to  have  to  keep  flipping  through  the  FI 
or  the  WD.  This  way  you  are  only  looking  at  what  points  you  need  instead  of  a  mass  configuration 
of  components  linked  together  as  with  the  FI. 

4.  Wiring  troubleshooting. 

5.  I  liked  the  ease  with  which  information  was  easily  attainable.  The  system  was  easy  to  use  as 
far  as  returning  to  different  screen  selections. 

6.  The  ease  of  making  a  fix  was  exceptional.  It  showed  me  certain  pans  that  I  would  not  have 
thought  of  being  bad.  Consolidating  the  TOs  and  use  of  the  correct  effectivity  automatically  makes 
troubleshooting  quicker. 

7.  I  can  troubleshoot  much  faster  and  efficiently. 

8.  It  provided  more  detailed  information  than  the  Fault  Isolation  manual. 

9.  Part  history,  showing  some  things  that  the  FI  does  not  show.  If  this  system  does 
everything  I’ve  been  told,  ordering  parts  from  the  line,  seeing  how  many  parts  are  in  supply,  ending 
the  job  at  the  line,  instead  of  coming  in  off  the  line  to  do  paperwork. 

10.  I  like  the  fact  that  I  have  all  the  TOs  I  need;  the  CAMS  work  and  supply  ordering  are  also 
facilitated.  It  enables  an  inexperienced  troop  to  perform  the  work  better  and  easier. 

11.  Faster!  In  the  expect  of  Supply  and  smaiier  class  to  carry  than  TOs.  [This  technician  liked 
the  idea  of  a  link  to  supply.  Also,  he  believed  the  portable  computer  would  be  easier  to  carry  than  the 
current  TOs.] 

12.  The  fact  that  you  do  not  need  to  skip  between  different  tech  orders.  The  idea  of  updates  of 
tech  data  via  computer. 
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(25)  What  did  you  dislike  about  the  automated  system? 

1.  Great  system!  Possibly  more  flexibility  on  finding  theory  and  schematics  would  help. 

2.  N/A 

3.  I  basically  have  no  complaints  with  the  system.  I  have  enjoyed  and  very  much  appreciate 
the  opportunity  to  work  with  this  system.  Thanks. 

5.  The  system  could  use  some  work  on  the  graphics,  also  a  change  in  the  software.  By  this  I 
am  referring  to  the  way  in  which  the  steps  of  the  task  are  displayed:  Instead  of  pushing  the  down 
arrow  to  read  remaining  steps,  you  should  push  NEXT  to  display  those  steps  on  the  next  page. 

6.  My  only  problem  with  this  system  is  when  I  paged  forward  and  was  unable  to  back  up.  The 
other  was  the  arrows  for  more  text.  At  times  I  missed  them  or  failed  to  notice  them. 

7.  The  computer  is  too  large  and  fragile. 

8.  The  size  and  clarity  of  the  graphics.  Also,  it  offered  no  information  pertaining  to  wiring 
diagrams. 

9.  There’s  a  lot  of  stuff  (directions)  not  needed  for  an  experienced  person.  When  told  to  repair 
a  wire,  that’s  all  it  said:  REPAIR  WIRE.  It  didn't  say  if  there  were  connections  within  the  aircraft. 
There  could  have  been  100  yards  of  wire  with  20  connections  and  all  it  said  was  to  REPAIR  WIRE. 

10.  The  inability  to  provide  info  on  wiring,  the  use  of  graphics:  Each  step  needs  at  least  the 
option  of  seeing  "the  picture."  I  didn't  like  the  inability  to  examine  the  procedures  without  actually 
performing  the  task. 

11.  No  preview  option. 

12.  The  fact  that  you  can't  skip  procedures  if  you  determine  it  is  not  required. 

(26)  If  you  had  a  choice,  would  you  use  the  computer  or  paper  TOs?  Why? 

1 .  Depends.  In  some  cases  (red  balls)  paper  TOs  would  probably  be  quicker  because  of  the 
setup  time  of  the  computer  when  you  troubleshoot  by  indications  only. 

2.  Computer  won’t  blow  down  the  ramp  and  ease  of  use.  Easier  to  carry  around  than  a  bunch 
of  TOs. 

3.  Computer,  definitely.  It  saves  the  hassle  of  carrying  TOs  to  the  job  site,  and  gives  much 
clearer  picture  of  what  steps  to  do. 

4.  Depends  on  the  job  how  simple  or  how  fast  need  to  do  the  job  like  RED  BALLS  and  jobs 
between  flights  you  may  not  have  time  to  troubleshoot. 

5.  Computer.  The  computer  was  much  easier  to  handle  and  work  with. 

6.  Computer.  The  computer  helps  to  make  troubleshooting  easier.  It  gives  you  more 
probabilities  than  an  FI  would.  A  lot  of  faults  would  have  to  be  researched  in  TOs,  whereas  the 
computer  gives  you  the  likely  faults. 
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7.  Computer.  I  think  it  saves  time. 

8.  For  the  majority  of  our  jobs  performed  on  the  flight  line,  I  would  prefer  to  use  the  paper 

TOs. 

9.  Because  of  the  radar  system  containing  a  lot  of  LRUs,  I'd  use  the  TOs.  If  we  replaced  an 
LRU  and  it  didn't  fix  the  problem,  then  the  computer  would  be  better  because  it  would  tell  you  the 
options. 

10.  At  this  stage,  I  would  prefer  the  TO,  because  I  usually  only  need  to  look  at  a  couple  of 
steps  and  would  rather  avoid  trudging  through  the  computer,  having  to  stop  after  each  step  to  hit 
"NEXT." 

11.  Computer.  Saves  time. 

12.  Computer. 

(27)  What  would  you  do  to  improve  the  automated  system? 

1.  Possibly  a  picture  of  scope  (REO)  indications  would  help. 

2.  Add  more  theory  available  through  it,  because  if  it  does  end  up  replacing  the  TO,  there  is  a 
lot  of  valuable  information  the  maintenance  person  sometimes  needs  to  find  out  about  a  certain  mode 
or  something  to  that  function. 

3.  Keep  making  the  progress  you  are  and  I  am  sure  it  will  be  a  great  piece  of  work  equipment. 

5.  The  system  does  need  some  changes,  but  I  feel  they  are  not  major.  An  example  would  be 
graphics. 

6.  I  would  like  to  see  it  smaller  as  I  was  told  it  would  be.  Possibly  the  diagrams  be  made  more 
legible  and  have  the  arrows  directing  more  text  be  more  in  view. 

7.  Add  more  graphics. 

8.  More  attention  needs  to  be  given  to  the  graphics  of  the  system. 

12.  Provide  a  scan  function  that  allows  you  to  look  at  different  procedures  to  establish  a  course 
of  action. 

(28)  Do  you  foresee  any  problems  in  using  a  computer  on  the  flight-line  for  maintenance?  If  so, 
what  would  be  required  to  overcome  these  problems? 

1.  No  real  problems  except  that  the  computer  has  to  be  made  very  rugged. 

2.  No,  I'm  all  for  it.  It  would  mean  ease  of  maintenance  and  save  manhours,  in  turn  saving  the 
government  money. 

3.  None  whatsoever,  not  even  the  fear  of  sunlight,  it  appears  to  work  clear  as  ever  in  the  sun. 

5.  No. 

6.  No.  I  would  like  to  see  this  computer  come  out  quicker  than  they  expect  it  to. 
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7.  The  computer  is  much  too  fragile  for  flight  line  use  on  a  regular  basis. 

9.  Problems  I  see  are  experienced  personnel  that  see  MFLs  "know"  what's  wrong.  They 
might  not  want  to  even  plug  it  in  until  they’re  finished. 

10.  Ensure  the  computer  is  weatherproof  and  able  to  take  the  shock  of  being  dropped. 

11.  No. 

12.  Need  to  insure  unit  is  shock/weather- proofed  to  enable  it  to  stand  up  to  use  and  climatic 
conditions.  Batteries  need  to  be  long  lasting  and  resistant  to  memory  build-up. 
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APPENDIX  C 


SAMPLE  DIAGNOSTIC  RUN 

The  diagnostic  process  using  PCMAS  as  an  aid  can  best  be  understood  by  following  a  typical 
scenario  from  the  beginning  to  the  end.  When  IMIS-DD  was  demonstrated  at  Homestead  AFB,  a 
careful  accounting  of  the  carious  paths  taken  through  the  diagnostic  sequence  was  made  and 
analyzed  (see  Section  4).  litis  appendix  is  a  composite  path  for  a  single  symptom  that  includes 
many  of  the  possible  side  trips  to  review  forms,  switch  between  novice  and  expert  levels,  and  to 
generally  exercise  the  capabilities  of  PCMAS. 

Each  step  in  the  process  produces  a  new  screen-full  of  information  which  the  technician  uses  to 
determine  his  or  her  course  of  action.  It  should  be  noted  that  the  screens  were  printed  from  a  Sun 
workstation;  thus,  they  differ  slightly  in  appearance  from  the  screens  displayed  on  the  PMA. 


D4bl 


Man  Number 

: 

System 

JCN 

:  1284212 

Priority 

York  Center 

i  A7CS 

Start  Hour 

A/C  H)  Number 

:  810794 

Stop  Day 

Location 

i  Bay  12 

Stop  Hour 

Tioe  Spc  Req 

:  1245 

Crew  Size 

Crit  ID 

«  N/A 

Type  Moint 

Crit  Narac 

i  N/A 

*facn  Disc 

DISCRErENCY 

1 

RPR-595 

Radar  inop  or 

degraded 

ress  filter  to  cont  inu*> 


Screen  1  -  Shows  a  partially  filled-in  AFTO  Fonn  349.  This  form  is  a  simulation  of  the  type  of 
form  that  will  be  received  directly  from  the  IMIS  workstation  in  a  fully  implemented  system.  It  is  a 
combination  of  data  that  will  be  originated  from  the  pilot  debriefing  process  and  from  unloading  the 
Data  Transfer  Cartridge. 

A  brief  description  of  each  of  these  fields  is  provided: 

JCN  (Job  Control  Number):.  This  will  be  assigned  by  the  workstation  and  will  be  unique  to  each 
task. 

Work  Center:  Identifies  the  location  of  the  work  to  be  performed.  A7CS  was  the  hangar  where  the 
IMIS-DD  demonstration  took  place  at  Homestead  AFB. 

A/C  ID  Number:  The  tail  number  of  the  aircraft  with  the  maintenance  need.  The  tail  number  is  used 
by  the  PMA  to  deliver  data  designed  specifically  for  that  aircraft  configuration/version. 

Location:  Bay  12  of  the  work  center. 

Time  Spc  Req:  The  time  the  specialist  is  required  to  be  at  the  aircraft. 

Crit  ID:  Criticality  Identification. 

Crit  Name:  Criticality  Name. 

System:  Identifies  the  general  system  of  the  aircraft  with  the  failure.  This  is  deduced  from  the 
failure  code  that  comes  in  from  the  debriefing.  9461  is  the  Radar  subsystem  on  the  F-16. 

Priority:  Assigned  by  the  maintenance  supervisor.  This  depends  on  how  important  it  is  to  get  that 
aircraft  back  in  service. 
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Start  Hour:  Contains  the  time  that  the  maintenance  technician  actually  started  this  task. 

Stop  Day:  Will  be  filled-in  automatically  when  the  task  is  complete. 

Stop  Hour:  Automatically  filled-in  at  the  completion  of  the  maintenance  action. 

Crew  Size:  This  will  be  calculated  by  the  IMIS  workstation  based  on  the  fault  and  the  number  of 
technicians  needed  to  complete  the  job. 

Type  Maint:  Type  of  maintenance  action.  For  example,  "B"  indicates  unscheduled  maintenance. 

When  Disc:  When  the  fault  was  first  discovered.  For  example,  "D"  indicates  during  flight  with  no 
abort  of  the  mission. 

DISCREPANCY:  The  MFL  code  and  its  English  language  description  of  the  symptom.  This 
provides  a  starring  point  for  the  diagnostic  process.  The  example  shows  only  one  MFL  present, 
RDR-595;  but  several  could  have  been  shown  and  each  would  contribute  to  the  maintenance 
decisions  made  by  the  diagnostic  module. 

At  the  completion  of  the  job,  the  remaining  349  form  entries  will  be  automatically  filled-in  by  the 
PMA. 


Screen  2  -  The  technician  enters  his  or  her  5-digit  Man  Number.  In  the  full  IMIS  system,  this 
number  would  uc  compoieu  wiJi  a  iisi  of  possible  and  authorized  Man  Numbers  contained  in  the 
base  personnel  computer  system.  The  training  level,  skill  level  and  security  level  assigned  to  that 
technician  would  also  be  compared  with  the  requirements  of  the  task. 
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t  r*>V 


««m»,CTWEBHBBaia 


ax 


Man  Nutber 

33333 

Systea 

I  9461 

JCN 

1284212 

Priority 

:  2 

fork*  Center 

A7CS 

Start  Hour 

i  0003 

A/C  11)  Nuaber 

810794 

Stop  Day 

: 

Location 

Uayl2 

Stop  Hour 

i 

Tioe  SpC  Req 

1245 

Crev  Size 

:  2 

Crit  ID 

N/A 

Type  Maint 

i  B 

Crlt  Name 

N7A 

JFhen  Disc 

l  D 

DISCRHPCNCY 

RIK-595 

Radar  Inop  or  degraded 

7 


Screen  3  -  The  AFTO  Form  349,  with  the  Man  Number  filled-in,  is  now  ready  for  use  during  the 
diagnostic  process. 
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Screen  4  -  The  first  menu  is  presented  to  the  technician.  The  following  options  are  available: 

"Begin  New  Session"  -  Start  the  diagnostic  procedure.  If  the  technician  had  interrupted  a 
procedure  for  some  reason,  the  number  2  option  would  be  to  resume  the  previous  session  where  it 
was  interrupted. 

"History"  •  Present  the  history  of  this  tail  number  for  review. 

"Component  Availability"  -  Shows  the  number  of  LRUs  available  in  supply. 

"Review  349"  -  Presents  the  349  form. 

"Quit  MDAS"  -  End  the  diagnostic  session. 
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HISTORY 


SYSTEM  HISTORY 

Tail  Nub bor  :  820954 

1.  Job  Control  Number  :  8901329 

Work  Unit  Code  :  231BJ 

Discrepancies  -  FCR  antenna  not  elevated  by  AN''  svitch. 

Corrective  Action  -  Rep laced  Fwd  Throttle  Grip. 

2.  Job  Control  Number  :  8956384 

Work  Unit  Code  :  74AITO 

Discrepancies  -  LPRF  Oscillator  calibration  tales. 

Corrective  Action  -  Replaced  LI’Rf  ■ 


e.nrerv.tcii 


Screen  5  -  If  the  technician  had  selected  History,  the  portable  would  present  the  simulated  repair 
history  for  the  specific  aircraft  in  latest-first  format.  In  the  full  IMIS  system,  the  historical  data 
would  come  from  CAMS.  This  screen  shows  the  last  two  operations  performed  on  the  aircraft: 
replacement  of  the  forward  throttle  grip  and  replacement  of  a  Low  Power  Radio  Frequency  (LPRF) 
LRU  from  the  Radar  subsystem. 
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AYAJMflILUY  OF  LRU'S 


Description  Number  Available 


FCR  Cable  Assembly  * 

REO  2 
Aft  Side  Stick  Controller  2 
Aft  Throttle  Grio  2 
Radar  Antenna  Assembly  5 
Digital  Signal  Processor  2 
Fire  Control  Coaputer  2 
FCR  Computer  2 
Forwcrd  Side  Stick  Controller  2 
Fwd  Throttle  Grip  2 
Lot  Pcmer  RF  Uni-  2 
Nacelle  Eq  Bay  AC/DC  Pwr  Panel  5 
Radar  Control  Panel  2 
Side  Stick  Controller  2 
Throttle  Grip  3 
Yavegulde  Assembly  2 
FCR  Transmitter  2 


Screen  6  -  If  the  technician  had  selected  the  Component  Availability  option,  the  LRUs  in  stock  for 
this  configuration  of  aircraft  would  be  shown.  This  is  simulated  data  showing  the  type  of 
information  that  would  be  retrieved  from  the  CAMS  system  via  the  IMIS  workstation. 
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Select  Action: 


1  Saf mg  Exterior 

2  Safing  the  cockpit 

3  Safing  electrical  power 

4  Initialize  Aircraft  and  Verify  Faults 

5  Safing  hydraulic  oower 

f>  Connect  Electrical  Power  to  Aircraft 
7  Apply  Cooling  Air  to  Aircraft 
0  Begin  Diagnostics 


Screen  7  -  The  initial  menu  allows  the  technician  to  proceed  through  any  of  the  safing  procedures 
listed,  initialize  the  aircraft  and  verify  the  faults  (item  7),  or  start  the  diagnostic  process  by  selecting 
"0." 
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TASK:  Initialize  Aircraft  and  Verify  Faults 


igTsramuiiugi 


Applicability:  All 

Required  Conditions: 

•  Aircraft  Safe  for  Maintenance 

•  Po%er  off 

•  pQiiel  2308  open 

Personnel  Recommended:  One 
Support  Equipment:  None 
Supplies  (Consumables) :  None 
Other  Reco«u*endat  ions:  None 


NI'XT 

HACK 

KUKN 

[■■1 

1 

i 

Screen  8  -  When  the  technician  selects  "7"  in  the  previous  screen,  the  initialization  of  the  aircraft 
and  verification  of  the  fault  begins.  This  screen  shows  the  input  conditions  to  that  operation. 
Pressing  "NEXT"  allows  PCMAS  to  proceed. 
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TASK:  0 pen  Access  Door  2308 


mmmamstssssm 

Applicability:  All 

Required  Conditions: 

»  Aircraft  safe  for  maintenance 

Personnel  Recomaended:  One 

Support  Equipment:  None 

Supplies  (Consumables) t  None 

Other  Recommendations:  None 


[  NEXT 

MACK 

|  RMRN  1 

■■■1 

IHBil 

11 

is 

Screen  9  -  The  first  task  is  to  open  access  door  2308.  The  input  conditions  for  this  task  are  shown 
here. 


Screen  10  -  The  expert  track  for  this  step  shows  only  the  general  location  of  door  2308. 


TASK:  Initialize  Aircraft  and  Verify  Faults 


12  Attach  tnax  cable  between  PCMAS  and  aircraft  TISL  port. 


NfcXT 

BACK 

RF.TKN 

[■■■ 

Screen  1 1  -  The  technician  is  instructed  to  attach  PCMAS  to  the  aircraft  1553  bus  via  the  TISL  port. 


TASK:  Open  Access  Door  2318 

■vmimwniipsan 

Applicability:  All 

Required  Conditions: 

♦  Aircraft  safe  for  maintenance 

Personnel  Recommended:  One 

Support  Equipment:  None 

Supplies  (Consumables) :  None 

Other  Recocaendat ions:  None 


mmmmm 

|  NEXT  | 

|  BACK  j 

j  RbTRN  | 

\mmm 

■  y 

■j 

mmii 

Screen  12  -  The  input  conditions  for  the  next  task  (Open  Access  Door  2318). 
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TASK:  Connect  Electrical  Twer  to  Aircraft 


cioniff 

Do  a*t  allow  the  fleoerator  set  cable  to  rest  oa  or 
force  opes  access  door.  Damfe  to  tte  door  cai 
ream. 


][ 


: 


Screen  14  -  The  technician  is  cautioned  against  damaging  the  door  with  the  generator  set  cable.  To 
proceed  past  this  point  the  technician  will  have  to  press  "ENTER”  on  the  keyboard  (not  shown  on 
screen)  rather  than  "NEXT". 


Screen  15  -  The  technician  is  directed  to  connect  power  to  the  aircraft  and  turn  the  generator  on. 
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TASK:  Initialize  Aircraft  and  Verify  Faults  _ ] 


Screen  16  -  Directions  to  set  cockpit  switches  for  the  test. 


TASK:  Initial iz--  Aircraft  and  Verify  Faults 


Insure  FCC  and  I\S  urc  turned  off  using  stitches  on  FCNP. 


Screen  17  -  Directions  to  shut  down  the  FCC  and  INS.  When  power  is  removed  from  these  two 
LRUs,  PCMAS  will  be  able  to  take  control  of  the  1553  communications  bus. 


Screen  1 8  -  The  Data  Transfer  Cartridge  contains  a  record  of  all  the  faults  that  the  aircraft  has 
experienced  during  the  last  flight.  This  step  ensures  that  the  cartridge  is  installed  in  the  cartridge 
reader  and  ready  to  be  read  by  PCMAS.  When  the  technician  answers  "YES,”  PCMAS  will  unload 
the  fault  codes  from  the  cartridge  into  its  own  memory  to  shirt  the  diagnostic  process. 

If  the  technician  selects  "NO,”  the  operation  of  reading  the  cartridge  will  be  bypassed. 
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CURKFNI  OPTION: 
TASK:  Power  On 


KCR  Built-In  Test 


fAlUl  in.v* 


Appl icabil ityi  All 

Required  Conditions: 

•  Aircraft  safe  for  maintenance 

•  Po%er  on  aircraft 

•  INS  off 

»  FCC  off 

Personnel  RecoKaended:  One 
Support  Equipment:  None 
Supplies  (Consitoebles) :  None 
Other  Kecocaendations:  None 


NOT 

BACK 

RETRN 

Ml 

][ 


Screen  19  -  This  screen  shows  the  input  conditions  for  running  the  FCR  Built-In  Test.  It  shows 
that  power  should  be  applied  to  the  aircraft  and  that  the  INS  and  FCC  should  be  powered-off  to 
allow  PCMAS  to  control  the  1553  bus. 
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CURRENT  OPT I  ON: 
TASK:  Power  On 


PCR  BIT 


E£ 

a.  (A)  Ensure  FLCS  PWR  switch  to  NORM. 

b.  (A)  Fnturc  main  power  switch  to  WAIN  PTR. 

c.  (A)  Ensure  FCC  power  off  via  switch  or.  FCNP. 

d.  (A)  Ensure  INS  power  off  via  switch  on  FCNP. 

e.  <A)  Cycle  MOOR  SWITCH  on  Radar  Control  Panel  to  OFF  then  back  to  AIR  position. 

MAIN  POWER 
SWITCH 


TLCS  l*IR 
SWITCH 


TYPICAL 


|  NEXT  |  BACK  |  RfcTRN 

INfO 

CNTRL  | 

Screen  20  -  The  complete  setup  to  perform  BIT  is  shown  in  this  screen.  Each  switch  is  identified 
and  located  in  the  cockpit  for  the  maintenance  technician. 


CURRENT  OPTION: 
TASK:  Perform  OIT 


,"CR  HIT 


1  YES 

2  NO 


Has  1553  trlax  cable  been  connected  frcm:  the  portable  computer  to  the  aircraft  TIS1 
port? 


HACK 

RETRN 

i  i! 

f _ LL 

CNTRL  ] 


Screen  21  -  This  question  is  asked  of  the  maintenance  technician  as  the  last  step  in  preparation  for 
BIT  execution.  If  the  technician  answers  that  the  PMA  is  connected  to  the  aircraft  via  the  TISL 
port,  the  portable  will  initiate  BIT.  If  the  technician  answers  "NO,"  then  the  PMA  allows  the 
technician  to  manually  run  the  BIT  and  enter  the  results  into  the  portable  computer. 
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CURRENT  OPTION:  FCR  Built-In  Test  ~  | 

TASK:  Perform  BIT  ’ 


Synptcwis  fro«  the  Built  In  Test: 

RDR-595  Radar  inop  or  degraded 

Symptocs  froa  the  349: 

RDR-595  Radar  mop  or  degraded 


|  NEXT  j 

il'i  f  B  ‘iB1 

1 

i 

Screen  22  -  The  results  of  the  BIT  test  are  displayed  to  the  technician  in  both  the  MFL  code  (RDR- 
595)  and  the  English  language  interpretation  of  the  code  (Radar  inop  or  degraded).  The  symptom 
from  the  349  form  is  also  displayed  to  act  as  a  reference  point  to  the  beginning  of  the  maintenance 
session. 
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CURRENT  OPTION:  FCR  Built-In  Test 

TASK:  Perforn  BIT 

u  (A)  Power  up  the  FCC  by  depress inai  the  switch  on  the  FCNP. 


Screen  23  -  The  technician  is  being  directed  to  power-up  the  FCC  in  order  to  restore  the  aircraft  to 
the  state  it  was  in  before  the  BIT  test  was  initiated. 
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Select  Action: 


1  Safing  Lxterior 

2  Safing  the  cockpit 

3  Safing  electrical  power 

4  Apply  Cooling  Air  to  Aircraft 

5  Safing  hydraulic  power 

6  Connect  Clectricai  Power  to  Aircraft 
0  Begin  Diagnostics 


L 


Screen  24  -  The  menu  shown  in  screen  7  is  reentered  to  allow  the  diagnostic  process  to  continue. 
Notice  that  the  task  just  completed,  Initialize  Aircraft  and  Verify  Faults,  has  been  removed  from  the 
menu. 


78 


CURRENT  OPTION:  (i)  Check  LPKF/C<wp.  Cable 


Fire  Control  Radar 


\  in:**.! <  ,  .  i  '*»  ?  + 

X  )*«««,'  /  *  |  ♦  Vy/h 
»  8  i  x  l 


I  \  K 
S  i  gnn I 
Pivcfsxinu 


FCR 

Mode 

Control 


«acsa 


NEXT 

1 

INTO 

OPTN  1  I 


TOC 


OfTRl 


Screen  25  -  If  the  technician  selects  "0,"  the  first  functional  diagram  is  created  and  displayed  for 
him  or  her.  This  diagram  indicates  that  the  Current  Option  (top  of  screen)  is  to  "Check 
LPRF/Comp  Cables".  From  the  shading  of  the  block  diagram,  you  can  see  that  the  operation  will 
be  concerned  with  the  FCR  Signal  Processing  portion  of  the  Radar  subsystem  (black-boxed 
letters).  By  pressing  1,  2,  or  3,  the  technician  will  be  presented  with  a  breakdown  of  the 
components  in  the  selected  area.  The  selected  procedure  may  be  invoked  by  pressing  "NEXT." 
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CURRENT  OPTION!  (1)  Check  LPRF /Coup.  Coble 


FCR  Signal  Proccessing 


||  NEXT 

1  ' 

INTO 

OPTN 

TOC  CNIRl. 

Screen  26  -  In  this  case,  the  technician  wanted  to  view  the  block  diagram  of  the  signal  processing 
subsystem.  This  diagram  shows  the  principal  LRUs  that  make  up  the  subsystem  (connected  with 
lines),  as  well  as  the  individual  waveguide  connections,  the  LPRF  Cables,  and  the  wiring  (in 
isolated  boxes).  This  convention  allows  an  otherwise  complex  diagram  to  be  shown  in  a  compact 
manner. 


The  shading  on  this  diagram  indicates  that  the  LPRF,  FCR  Computer,  and  the  LPRF  Cables 
(Comp)  are  suspects  in  the  failure  and  the  LPRF  Cables  (Comp)  will  be  tested  by  the  CURRENT 
OPTION. 
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CURRENT  OPTION:  (1)  Check  LPRF/Co»p.  Cable 


FCR  Mode  Control  for  All  A  Aircraft 


I  NEXT 

j  INFO  OPTN  TOC  |  CNTRl. 

Screen  27  -  If  the  technician  wanted  to  see  the  block  diagram  for  the  FCR  mode  control,  he  or  she 
would  have  selected  #2  instead  of  #1  in  screen  25.  This  screen  is  displayed  for  the  FCR  Mode 
Control. 


Screen  28  -  This  is  the  block  diagram  for  the  FCR  Power  (option  #3  in  screen  25). 


CURRENT  OPTION:  (I)  Check  LPRF/Co»p7  Coble 


r^-r  1  r  back  ~j  f~Rf?TiiN~~[  f 
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Screen  30  -  At  any  point  the  technician  can  select  the  "OPTN"  key  to  see  what  the  recommended 
options  are  at  this  point.  The  "Best  Options"  list  is  the  list  of  interleaved  test/repairs  recommended 
by  the  diagnostic  module.  "Ranked  Repairs"  displays  the  best-ranked  repairs,  and  "Ranked  Tests" 
displays  the  best-ranked  tests.  "Verify  LRU"  allows  the  technician  to  choose  any  LRU,  and  all 
repair  and  test  options  for  that  LRU  will  be  presented  in  a  menu. 
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CURRENT  OPTION:  (1)  Check  LPRF/Coap.  Cable 


7 


BEST  OPTIONS 

Description 

Hours  Fall  Prob  Ref  Des 

1.  Check  LPRF/Comp.  Cable 

0.4  20%  NA 

2.  Replace  FCR  Computer 

1.2  SOX  9473A5 

3.  Repair  LPRF/Cowputer  Coble 

0.4  20X  N/A 

4.  Replace  Lorn  Power  RF  Unit 

1.9  30X  9473A4 

|  NEXT 

I  BACK  1 

RETRN  j 

|  1  INFO  ] 

OP  IN  | 

TOC  CNTRL 

Screen  31  -  If  the  technician  selected  Best  Options,  this  screen  would  be  presented.  It  shows  some 
of  the  factors  that  MDAS  used  in  recommending  the  best  action  to  perform.  It  also  shows  the  rank 
order  of  the  other  possible  recommended  actions.  Notice  that  even  though  "Replace  FCR 
Computer"  has  a  higher  probability  of  causing  this  failure,  50%  as  opposed  to  20%  for  the  first 
choice,  MDAS  has  recommended  "Check  LPRF/Comp.  Cable"  because  of  the  lower  time  needed  to 
perform  the  test.  (See  Section  II  for  a  full  description  on  how  MDAS  makes  its  recommendations.) 
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CURRENT  OPTION:  (2)  P.eplece  FCR  Coaputer 


FCR  Signal  Processing 


Vavcgulde  Connections 


LPRF  Cables 


Xutr 

LPRF 

Ant 

X*tr 

DSP 

slngCntailim 

•UF3U 

♦<«*♦)»>*•«• 

Vinng  1 

NEXT 


INFO 


OPTN 


TOC 


CNIRL 


Screen  32  -  This  screen  shows  how  the  components  are  spanned  for  the  second  best  option, 
"Replace  FCR  Computer"  (upper  left  of  the  display).  The  technician  may  select  this  option  for 
reasons  of  his  or  her  own  of  which  MDAS  might  have  no  knowledge. 


Screen  33  -  The  technician  has  chosen  to  start  the  diagnostic  process  with  the  first  option  after  all 
(Check  LPRF/Comp.  Cable).  The  input  conditions  to  this  task  (Check  Cable  Continuity)  are 
shown  as  the  first  piece  of  information. 


CURRENT  OPTION:  Check  Cable  Assembly  between  LPRF  and  FCR  Computer 

TASK:  Open  Access  Door  1202 

Applicability!  All 

Required  Conditions! 

•  Aircraft  safe  for  maintenance. 

Personnel  Recommended:  One 

*  Technician  opens  end  closes  door. 

Support  Equipment! 

Maintenance  Platform,  Type  B-4A  or  equivalent. 

Supplies  (Consumables) i  None 
Other  Recommendations:  None 


NEXT  | j  BACK 

j  j  RF.TRN  | 

!  j  INTO 

CNTRI. 

Screen  34  -  The  procedure  to  open  access  door  1202  is  automatically  linked  to  this  task  and  the 
input  conditions  are  displayed  for  the  technician.  It  indicates  that  a  Maintenance  Platform  will  be 
required  and  only  one  person  is  needed  to  do  the  procedure.  The  technician  will  press  the  NEXT 
function  key  after  reading  the  text. 


CURRENT  OPTION:  Check  Cable  Assembly  between  LPRF  and  FCR  Computer 

TASK:  Open  Access  Door  1202 


Screen  35  -  The  procedure  for  opening  the  access  door  also  has  a  Caution.  To  proceed  past  this 
!  point,  the  technician  must  press  the  "Enter"  key  on  PCMAS  rather  than  the  "NEXT"  function  key. 

This  will  prevent  the  technician  from  simply  pressing  the  next  key  without  acknowledging  the 

!  cautions. 

f 

I 

I 
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Screen  36  -  A  graphic  to  locate  the  proper  door  is  displayed  to  the  technician.  This  is  die  expert 
track  of  data  for  the  task.  If  more  detail  is  desired,  the  technician  can  press  the  "MORE"  function 
key. 


89 


Screen  37  -  The  novice  track  of  data  also  contains  a  caution  that  must  be  read  and  responded  to  with 
the  "Enter"  key. 


Screen  38  -  The  novice  track  displays  more  detail  about  the  use  of  the  door  strut  and  support 
bracket. 
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Screen  39  -  In  the  expert  track,  this  is  the  first  screen  the  technician  will  see  for  the  actual  continuity 
check  procedure.  The  to/from  pins  are  presented  in  a  table  for  best  access.  This  screen  also 
displays  a  question  (Yes/No)  that  must  be  answered  to  proceed.  MDAS  will  rely  on  the  Yes  or  No 
response  to  this  question  to  recommend  the  next  best  action. 
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Screen  40  -  The  novice  track  of  the  same  task  shows  a  graphic  to  identify  the  cables  attached  to  the 
FCR  Computer. 


Screen  41  -  The  novice  track  then  shows  a  graphic  to  locate  the  other  end  of  the  cable  at  the  LPRF. 
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Screen  42  -  The  novice  track  asks  the  same  question  that  was  asked  of  the  expert  in  screen  38, 
except  this  question  helps  the  technician  set  up  the  ohmmeter  and  interpolate  the  readings.  For  this 
scenario,  the  technician  indicated  that  he  had  found  a  bad  cable  by  entering  "NO." 


O.RRENT  OPTION:  Check  Coble  Asseofcly  between  LPRF  ond  FCR  Computer 

TASK:  Check  Coble  Continuity 


1  Yes 

2  No 


With  ohstweter  ot  lowest  scale,  weosure  resistance  between  the  center  pin  end  shield  of 
94735P4  ot  the  FCR  Computer.  Is  the  resistance  greeter  than  zero? 


RADAR  COMPUTER 
C9473A63 


COtfiECTOR 

[94735P13 

CONNECTOR 

1947351*23 


- 

u _ 

i  dack  i 

RETRN 

LESS 

INFO 

|  CNTRL 

Screen  43  -  This  novice  step  makes  sure  that  the  pins  are  not  shorted  to  ground  and  presents  a 
graphic  to  help  locate  the  cables.  The  technician  indicates  that  the  cable  is  not  shorted  to  ground  in 
this  scenario  by  again  answering  "NO." 
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Screen  46  -  When  the  reassembly  task  is  complete,  the  system  graphic  is  re-displayed.  The 
shading  has  been  changed  to  indicate  that  the  LPRF  and  FCR  Computer  have  teen  downgraded  as 
possible  causes  of  the  failure  (they  are  a  lighter  shade  of  grey),  and  are  members  of  the  "Maybe"  set 
for  diagnostic  purposes.  This  figure  also  shows  that  the  current  option  is  "Repair  LPRF/Computer 
Cable,"  which  was  found  to  have  failed  in  the  last  step. 
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CURRENT  OPTION:  (O  Repair  LPRF/Coaputer  Cable 


QUICK  INFO 


1  Input  Conditions  -  Repair  LPRF/Co«p  Cable 

2  Diagnostics  Status 


NEXT 


BACK 


RETRN 


INFO 


OP  IN 


TOC 


CNTRL 


Screen  47  -  If  the  technician  presses  the  "INFO"  function  key  when  Screen  45  is  being  displayed, 
die  Quick  Info  menu  wiil  appear.  At  this  point,  the  technician  can  choose  to  view  the  input 
conditions  or  review  the  diagnostic  status. 
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Screen  48  -  When  option  2,  "Diagnostic  Status",  is  selected  at  the  previous  screen,  this  menu 
appears.  At  this  point,  the  technician  is  given  the  choice  of  reviewing  his  or  her  previous  actions, 
the  symptoms,  or  the  availability  of  replacement  parts. 
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Screen  49  -  This  screen  shows  the  previous  actions  taken  thus  far  in  the  repair  procedure.  It  shows 
that  the  test  of  the  LPRF/Comp.  Cable  has  failed  (the  cable  is  bad)  and  that  an  access  door  is  still 
open. 


\ 
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CURRENT  OPTIONt  (1)  Repair  LPRF/Co«puter  Cable 


Select  operation  to  be  performed 


E 


1  History 

2  exponent  Availability 

3  kevlev  349 

4  Quit  WAS 


1 


Screen  50  -  The  technician  has  the  ability  to  terminate  the  diagnostic  run  at  any  point  through  the 
menu  displayed  when  the  "CNTRL"  function  key  is  pressed.  Other  options  available  here  are:  (a) 
review  the  history  of  the  aircraft,  (b)  see  which  LRUs  are  available  from  supply  (simulated  for  this 
demonstration),  or  (c)  review  the  349  form  that  started  the  maintenance  action.  If  "Quit  MDAS"  is 
selected,  another  menu  is  presented  with  two  options:  (1)  end  the  maintenance  session  completely, 
or  (2)  suspend  the  session  for  resumption  later  at  the  same  point  in  the  diagnostic  process. 
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CURRENT  OPTION:  (1)  Repair  LPRF/Computer  Cable 
TASK:  Repair  Cable 


Applicability*  All 

Required  Conditions* 

#  Access  door  1101  open 
»  Access  door  1202  open 

Personnel  Reco^ended*  One 

Support  Equipment*  None 

Supplies  (Consumables) :  None 

Other  Recommendations:  None 


I  NEXT  |  f  BACK  1 1  RETKM  IT 


j  INFO 


ir 


1 1  CNTRL 


Screen  5 1  -  If  the  technician  were  to  press  "NEXT"  rather  than  any  of  the  menu  items  on  the  last 
screen,  the  procedures  for  the  "CURRENT  OPTION"  would  be  invoked.  In  this  case,  the  Input 
Conditions  for  the  procedure  are  displayed  for  review. 
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CURRENT  OPTION:  <1>  Repair  LPRF/Coaputcr  Cable 
TASK:  Repair  Cable 


After  visual  inspection  to  verify  faulty  coaxial  connector,  repair  as  required. 


tl 


RADAR  COMPUTER 
[9473A6J 


(94735P11 

CONNECTOR 


CONNECTOR 

I94735P41 


[94732P41 


]|  NEXT 

BACK 

RETRN  |  MORE  | 

INFO 

1 

CNTRL 

Screen  52  -  This  screen  shows  the  expert  track  for  the  task  of  repairing  the  cable.  Notice  that  the 
"More"  function  key  is  available  to  allow  switching  to  the  novice  track  if  needed. 
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CURRENT  OPTION:  (1)  Repair  LPRF/Co*puter  Cable 
TASK:  Repair  Cable 

W  Remove  appropriate  coaxial  connector: 

a.  Verify  faulty  front  end  and  remove  fro*  the  aatlng  unltj  place  dust  cap  on  the 
exposed  *ating  unit. 

b.  Remove  cable  clanps  near  the  faulty  front  end. 

c.  Select  two  spanner  wrenches  sized  for  the  front  end  and  connector  body  attached  to 
the  cable. 

d.  Apply  counterclockwise  fforce  to  break  threads  (approximately  60-75  inch-pounds) . 
Unscrew  defective  front  end  by  hand  and  remove. 


Screen  53  -  The  "More"  function  key  has  been  pressed  and  the  details  of  the  cable  repair  in  the 
novice  track  are  presented  to  the  technician.  Notice  that  the  "More"  function  key  has  been  replaced 
by  a  "Less"  key.  This  allows  for  switching  back  to  the  expert  track. 


CLRRENT  OPTION:  (1)  Repair  LPRF/Computer  Cable 
TASK!  Repair  Cable 


Ml  Install  replacement  connecter: 

a.  Install  nev  replacement  front  end  by  hand  In  clockwise  direction)  If  angle  type, 
orient  to  its  proper  position  and  tighten  with  a  pair  of  spanners  and  torque  wrench 
adapter  set  for  45-53  Inch-pounds. 

b.  Remove  dust  cap  from  new  front  end  and  connect  to  Its  mate  fingertightj  then  torque 
coupling  nut  to  20-25  Inch-pounds. 

c.  Reinstall  cable  clasps. 


RADAR  COMPUTER 
I9473A61 


I94735PU 

COEJv'ECTOR 

(94735P2) 

CONnECTOR 

194735P43 


I94732P4) 


|  NEXT 

|  BACK 

[■rerai 

|  LESS 

_ 

INFO  | 

1 

CNIRL 

Screen  54  -  This  is  the  second  screen  of  instructions  at  the  novice  track  for  the  cable  repair. 
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Screen  55  *  Once  the  repair  is  complete  and  the  technician  presses  the  "NEXT"  function  key  from 
either  the  novice  or  the  expert  track,  the  input  conditions  for  the  next  task  are  displayed.  In  this 
case,  the  task  is  the  execution  of  the  Built-In  Test  to  verify  that  the  cable  repair  was  successful. 

Before  this  can  occur,  the  aircraft  must  have  been  safed,  power  applied,  and  the  INS  and  FCC  shut 
off.  Shutting  the  INS  and  FCC  off  is  necessary  to  allow  PCMAS  to  gain  control  of  the  bus. 
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Screen  56  -  The  complete  setup  to  perform  BIT  is  shown  in  this  screen.  Each  switch  is  identified 
and  located  in  the  cockpit  for  the  maintenance  technician. 
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Screen  57  -  This  question  is  asked  of  the  maintenance  technician  as  the  last  step  in  preparation  for 
BIT  execution.  If  the  technician  answers  that  the  portable  is  connected  to  the  aircraft  via  the  TISL 
port,  the  portable  will  initiate  BIT. 


4 

« 
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Screen  58  -  This  screen  shows  the  results  of  the  BIT  execution  (no  faults  found)  and  the  original 
MFL  symptom  for  reference. 


\ 

Screen  59  -  After  running  the  BIT  procedure,  the  technician  is  directed  to  return  the  cockpit  to  its 
operational  condition. 
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Failed  fault(s)  found.  Systen  function  check  passes. 


Screen  60  -  The  system  block  diagram  is  again  presented,  showing  that  all  symptoms  have  been 
exculpated  and  the  functional  check  has  passed. 


Screen  61  -  Now  that  the  diagnostic  process  is  complete,  the  technician  can  either  dose  up  the 
aircraft  or  quit  entirely. 
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Screen  62  -  The  option  to  "Close  Access  Door  1202"  was  selected  so  the  system  presents  this 
procedure  to  the  technician.  This  Caution  is  automatically  linked  to  the  procedure  to  ensure  the 
proper  order  of  fastener  reconnection. 
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Stop  Hour 
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I  N/A 
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DISCREPENCY 

I 
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Screen  64  -  After  the  close-up  procedure  is  complete,  the  349  form  is  again  displayed.  At  this 
point,  the  portable  has  entered  the  Stop  Day  and  Stop  Hour  fields. 
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fORK  UNIT 

ACTION 

HO* 

UNITS 

TIME 

STATUS 

CODE 

TAKEN 

MAL 

START  STOP 

74A99 

G 

943 

01 

1622  1624 

C* 

CORR  ACTION  i 

Repair  LPRF/Co»puter  Cable 


I*«>n  t  I 


Screen  65  -  The  bottom  part  of  the  349  is  shown  in  this  screen  with  the  data  supplied  automatically. 
The  WUC  has  been  completed  along  with  the  "action  taken"  code  and  the  HOW  MAL.  An  English 
language  description  of  the  fault  is  also  provided.  These  data  will  form  a  part  of  the  history  file  for 
the  next  maintenance  action  on  this  tail  number. 


Screen  67  -  End  of  Session. 
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